Security lessons from a month of real attacks

Security lessons from a month of real attacks
February 28, 2026 at 12:00 AM

Security headlines this month share a common thread: attackers are exploiting both the tools we use and the ways we manage them. From firewall takeovers to mobile trickery and cash machines gone wild, the underlying lessons repeat.

This piece pulls those lessons into a practical plan. The goal is not to recap news, but to show how different incidents point to the same gaps and how to close them.

Two fronts are converging: control planes and human interfaces

The control surface

One cluster of incidents centered on devices with exposed management interfaces. Attackers did not need exotic zero days, they needed ports left on the open internet and passwords that could be guessed or reused. Generative AI amplified this, lowering the effort to script mass discovery and login attempts and to chain small wins into access at scale. Recent reporting tied this pattern to hundreds of compromised firewall appliances across dozens of countries.

The trust surface

The second cluster targeted the human interface. Mobile malware adopted generative AI to make on-screen prompts and overlays feel native to what the person is doing. If a user is opening a banking app, a malicious overlay can time a fake prompt to that moment. The trick is not new, but AI makes it more convincing and more frequent.

Non-obvious lens: use the distinction of control surface versus trust surface. Control surface attacks work by turning your administration tools against you. Trust surface attacks work by turning your own expectations against you. If a story does not fit cleanly, ask which surface the attacker manipulated more. That guides where to invest next.

Consider a small service firm that outsourced firewall setup. The vendor briefly exposed the admin port for remote work and forgot to close it. Weeks later, the device is brute forced overnight, and the attacker plants a backdoor. The firm had strong endpoint security on laptops, but nothing was watching the control surface, so no alert fired.

Fortified, not exposed: fixing management-plane hygiene

Compromise of network appliances often starts with two facts meeting each other. First, the admin interface is reachable from the internet. Second, credentials are weak or shared, and multi-factor authentication is missing. Generative AI adds scale by generating credential permutations, writing glue code, and summarizing errors to keep the attack loop going. It is not magic, it is cheap persistence.

What to change this month

  • Remove public reachability of device management. Put admin interfaces behind a hardened jump host, a well configured virtual private network, or a zero trust access service. This works when you can enforce device posture on admins, and fails if you allow unmanaged browsers to reach the jump host.
  • Require multi factor authentication for every administrative login. Prefer phishing resistant methods such as security keys or device bound passkeys. This blunts brute force and credential stuffing, but fails if session cookies can be replayed or if there are break glass accounts without strong MFA.
  • Rotate unique admin credentials per device, disable defaults, and rate limit failed logins. This reduces the payoff of mass guessing, but fails if a device shares a directory service that grants broad admin rights by group.
  • Turn on logging and alerts for failed and successful admin logins, including source network and username. This detects the noisy phase of a takeover, but fails if logs are stored only on the device that gets wiped on reboot.

What not to do

Avoid relying on simple IP allowlists for admin access when those ranges include cloud egress addresses, because attackers can originate traffic from those same providers and blend in. Pair allowlists with identity, device compliance checks, and strong MFA. If you must allow temporary exposure for vendor support, use a time boxed rule with an automated expiry and an approval record.

Consider a regional manufacturer using a popular firewall. A partner asked for quick access, so an engineer opened the management port and planned to close it later. A password reused from a different system was guessed. The engineer had enabled SMS based verification, but only on the customer portal, not on the device itself, so it did not help.

Mobile malware learns context: guarding the trust surface

Researchers described Android malware that uses generative AI to shape prompts and overlays that match what is on screen. The likely path is familiar: abuse of accessibility services, notification listeners, or draw over other apps permissions to observe context, then present precise, timed requests. The mechanism works because the person expects a real prompt at that exact moment.

Reduce the blast radius

  • Harden mobile fleets with managed profiles. Block apps that request accessibility without a business need, and require justification for draw over other apps. This works when a mobile device management policy is enforced, and fails if personal devices access corporate apps without controls.
  • Limit sensitive actions to in app flows that do not rely on generic system prompts. For example, use an in app authenticator view rather than a system wide prompt when possible. This reduces overlay risk, but fails if the app exposes deep links that malware can trigger.
  • Teach the simple rule of context mismatch. If a pop up asks for banking credentials while using a ride hailing app, back out and relaunch. Works when people pause before typing, fails if the overlay perfectly mirrors the expected flow.

Anti-pattern to drop

Do not whitelist mobile apps based only on high app store ratings, because ratings do not reveal permission abuse or post update behavior. Require a review of requested permissions and update cadence. Pull apps that suddenly add powerful permissions without clear justification.

Consider a salesperson who installs a trendy AI photo enhancer. It asks for accessibility to “improve your experience,” which gets approved. A week later, while opening a banking app, a perfect looking prompt requests a password reset. The endpoint security app does not flag it, because the overlay uses allowed system features.

ATM jackpotting shows operational gaps

Cash out attacks succeed when criminals gain logical control over the payout mechanism. The path often involves outdated operating systems on terminals, exposed services that talk to the cash dispenser module, removable media left enabled, or remote management links without strong authentication. Malware then instructs the machine to dispense cash or to queue up a cash out under certain commands.

Controls that move the needle

  • Lock down the terminal: disable unused USB ports, password protect and lock the BIOS or UEFI, and require signed updates. This blocks quick install of jackpotting tools, but fails if technicians leave maintenance modes unlocked after service calls.
  • Segment the network so ATMs cannot reach core systems directly and cannot talk to each other. Monitor the few allowed protocols for anomalies. This works when allow rules are narrow, fails if a backdoor remote tool is permitted broadly for convenience.
  • Harden the operating system: remove unnecessary services, enforce application allowlisting for device drivers and dispenser interfaces, and monitor for unexpected command sequences to the cash module. This reduces post compromise actions, but fails if allowlists get disabled for troubleshooting and never re enabled.
  • Build operational friction: dual control for maintenance access, tamper evident seals checked at every visit, and independent cash reconciliation. These do not stop malware alone, but they reduce undetected dwell time.

Consider a small ATM operator that uses remote desktop to manage terminals. A phishing lure harvests a single technician password. The attacker pivots into the management server, pushes a modified service that talks to the dispenser, and schedules late night cash outs. Cameras record the cash, but nothing in the control path raises an alert.

Wipers in critical infrastructure: resilience over heroics

Wipers are different from ransomware. They are built to destroy, not to extort. In recent investigations affecting critical sectors, a wiper rode existing administrative pathways, then overwrote key files or partitions to halt operations. If your controls assume time to negotiate, a wiper removes that time.

Design for the blast, not the bargain

  • Tier administration and remove standing domain wide privileges. Use just in time elevation with short lived tokens. This limits lateral movement, but fails if emergency break glass accounts quietly become daily drivers.
  • Keep backups that cannot be changed by anyone who can log in to the domain. Use immutable storage and offline copies, and test restores on a schedule. This works when backup credentials and networks are separate, fails if backups mount with the same credentials that servers use.
  • Pre stage recovery for a small set of critical functions. Know how to rebuild identity and a minimal operations slice quickly. This reduces downtime, but fails if documentation lives only on systems that get wiped.
  • Segment operational technology from information technology, with data diodes or strict gateways where applicable. Monitor the bridges. This works when exceptions are rare and documented, fails if technicians add undocumented remote access for convenience.

Consider a utility contractor that manages patching for multiple sites. A stolen admin token lets an attacker push a script through remote management, which wipes the file systems of a subset of servers. The endpoint agent is installed, but it was granted broad exclusions for performance and never sees the write patterns as malicious. Recovery succeeds only where an offline backup set had been tested recently.

A four week triage that pays off

  1. Close every exposed management interface and force administrative access through a single controlled path with strong MFA. Verify by scanning your own external footprint and by attempting logins from an untrusted network. This works when the inventory is complete, fails if shadow devices or old test portals remain forgotten.
  2. Clamp down on mobile permissions that observe and draw over screens. Require justification for accessibility, review apps that request it, and remove those without a business case. This works when policy applies to all devices that touch sensitive data, fails if exceptions creep in through bring your own device policies.
  3. Harden high impact terminals and servers, including ATMs and management jump hosts. Remove unused services, lock boot paths, and monitor narrow protocol sets for anomalies. This reduces the success rate of both jackpotting and wipers, but fails if change control disables protections during urgent fixes.

Forward look, stated plainly: attacks that blend cheap automation with small configuration mistakes will keep outpacing bespoke exploits. Expect more convincing prompts on mobile and more opportunistic grabs at exposed admin ports. This trend should slow if platform vendors constrain overlay permissions further and if organizations materially reduce internet facing management, and it will accelerate if convenience keeps winning over hard boundaries.

Back…
More articles