Connect with us

Infosecurity

The Domain Name and Its Role in Cyber Forensics: Unmasking Digital Crime

Published

on

The Domain Name and Its Role in Cyber Forensics: Unmasking Digital Crime

When you type a website address into your browser, the Domain Name System (DNS) silently translates it into an IP address. This system, first standardized in 1984, made the internet accessible and fueled e-commerce. However, the same ease of registering a domain name for a few dollars also opens the door to cybercriminals. Understanding the domain name cyber forensics connection is now essential for investigators tracing malicious activity.

Cybercriminals routinely exploit domain names to launch phishing campaigns, deploy botnets, or execute brandjacking. For instance, they register domains that closely mimic legitimate company names—a tactic known as typosquatting. Alternatively, they redirect users to rogue servers that steal credentials. These attacks rely on the central role DNS plays in routing traffic. But here’s the twist: every malicious domain leaves behind digital footprints that forensic experts can follow.

How DNS Data Powers Cyber Forensics Investigations

In a typical cyber forensics investigation, analysts start by examining Whois records. These public databases contain registration details for each domain name and IP address block. Attackers often use fake names and addresses, but they cannot hide all traces. By correlating email addresses, IP identifiers, and registration patterns, investigators can map out entire criminal networks.

Building on this, domain-based threat intelligence involves linking newly registered domains to subsequent malicious activities. For example, a botnet’s infected nodes periodically beacon out to command-and-control domains. Analysts can trace these domains back to a smaller set of IP addresses. This approach helps security teams stay ahead of blacklists and detection systems.

Real-World Case: Uncovering a Casino Data Breach

In May 2016, a UK-based online casino hired Horizon Forensics to investigate a data breach that had cost millions in lost revenue. Attackers had stolen the head of security’s login credentials, accessed the customer database, and sold betting records to a marketing affiliate. That affiliate then sent phishing emails to high rollers, enticing them to switch to rival casinos.

Investigator Dean Olberholzer began by examining the IP and email addresses used in the marketing pitches. Using DNS data, he quickly correlated unique identifiers to recently registered domain names. Although the affiliate used the Moniker privacy service to anonymize registration details, Olberholzer traced email addresses across all domains ever registered—in reverse chronological order. He also cross-referenced data from Google AdSense, AdWords, Analytics, Facebook, and Skype.

This domain-centric approach revealed the affiliate’s true identity and location in Israel. Cash flowed from casinos to bank accounts in Cyprus, Seychelles, and Panama. A kingpin based in Thailand orchestrated the scheme, which had victimized several other casinos, causing an aggregate revenue loss of $500 million.

The Role of DNS in Detecting Phishing and Botnets

Phishing campaigns often rely on spoofed domains to trick employees into revealing credentials. Similarly, botnets use thousands of malicious domains to evade detection. In both cases, attackers set up dozens or hundreds of domains tied to a smaller subset of IP addresses. Forensic analysts can use DNS intelligence to spot these patterns early.

For example, a sudden spike in domain registrations mimicking a company’s name may signal an impending attack. Investigators can then proactively block those domains or monitor them for malicious activity. This proactive approach is far more effective than reacting after a breach.

Building Your Own Threat Intelligence with DNS

Many security teams now adopt a “roll your own” approach to threat intelligence. Instead of relying solely on external feeds, they combine DNS data with internal logs and public sources. This method blends the analyst’s experience with automated tools to create customized, relevant intelligence. Counterintuitively, this can save time because it focuses on the most relevant threats.

To get started, analysts can use tools like Whois Lookup to examine domain registration details. They can also monitor DNS query logs within their own network. By correlating suspicious domains with known attack patterns, they can uncover hidden connections.

Conclusion: Why Domain Name Intelligence Matters

As cybercriminals become more sophisticated, traditional detection methods often fall short. However, the domain name remains a weak link in their operations. Every malicious domain leaves a trail of registration data, IP addresses, and behavioral patterns. By integrating domain name cyber forensics into their workflows, investigators can unmask attackers, disrupt campaigns, and prevent future breaches.

Ultimately, the DNS is not just a technical protocol—it is a powerful forensic tool. Whether you are a security analyst or a business owner, understanding how to leverage domain intelligence can make the difference between a contained incident and a catastrophic loss.

Continue Reading
Click to comment

Leave a Reply

Your email address will not be published. Required fields are marked *

Infosecurity

AI-Powered Attacks on Siemens PLCs: What ICS Operators Need to Know Now

Published

on

Siemens PLC attacks

The Warning: AI Is Now Writing Exploit Scripts for Siemens S7 PLCs

Industrial control system (ICS) operators are facing a new kind of threat. Adversaries are using artificial intelligence to craft exploitation scripts specifically targeting Siemens S7 Series programmable logic controllers (PLCs). This isn’t a theoretical risk. It’s happening now, and it’s forcing a hard look at how critical infrastructure defends itself.

A joint advisory from CISA, the FBI, and other agencies—published on August 19—spells out the danger. Sectors like manufacturing, energy, water and wastewater, and food and agriculture rely heavily on these PLCs. The potential fallout is severe: disrupted industrial processes, safety incidents, unplanned downtime, equipment damage, and compromised sensitive data. In the worst cases, that translates to real-world harm—water service interruptions, energy grid instability.

How the Attacks Unfold: From Scanning to Lateral Movement

The attack chain is methodical. Threat actors first use legitimate scanning services like Censys and ZoomEye to find internet-exposed or poorly segmented Siemens S7 Series PLCs. Once they’ve identified a target, they deploy AI-generated scripts to probe for vulnerabilities. The advisory is blunt: PLCs connected to the internet are at high risk.

But the AI involvement doesn’t stop at initial access. It’s also being used to move laterally within networks and evade defenses. Attackers are combining open-source industrial automation libraries with AI-assisted scripting to create custom tools that mimic legitimate OT monitoring solutions. These tools can read and write to Siemens S7 PLC memory, configuration data, and ladder logic programs via the S7comm protocol.

The goal, according to the authoring agencies, appears to be persistent reconnaissance. They’re mapping out critical environments, understanding how they work, and positioning themselves for future disruptive operations. As the advisory states: “For capability development, actors are testing and refining their exploitation techniques against specific PLC models… For operational effects, actors are leveraging read access to understand target environments, enabling preparation and positioning for future write operations.”

Why This Marks a Turning Point in ICS Attacks

The use of AI to generate exploit scripts is a genuine evolution in threat actor capabilities. It lowers the barrier to entry. Scripts that once required deep PLC expertise can now be produced—or modified—with far less effort. This is a shift from manual, labor-intensive hacking to something faster and more scalable.

This advisory follows earlier warnings about Iranian state-backed hackers targeting internet-exposed industrial systems from brands like Rockwell Automation, Allen-Bradley, Schneider Electric, and Siemens. Those warnings were linked to attacks on water systems across multiple US states in early August.

Mitigation Steps: What ICS Operators Must Do Now

The advisory lays out a series of urgent measures. These aren’t optional checklist items; they’re essential to reducing risk. Key actions include:

  • Proactively hunt for indicators of compromise—watch for connections from non-engineering workstations, repeated connection attempts with varying parameters, or traffic from unexpected countries or IP ranges.
  • Conduct an immediate inventory of all Siemens S7 Series PLCs in your environment and apply critical patches.
  • Ensure PLCs are not accessible from the internet. Separate OT and IT networks entirely.
  • Strengthen access controls: restrict PLC access to authorized engineering workstations and enable multi-factor authentication for all remote access to OT networks.
  • Disable web servers and unused communication protocols on Siemens S7 devices.
  • Contact Siemens for model-specific hardening recommendations.

Special attention is needed for operators who work with third-party service providers or system integrators. These vendors may have remote access to PLCs, and asset owners may not even realize their systems are exposed. That’s a dangerous blind spot.

Expert Perspective: The Real Lesson Isn’t About AI

Benny Czarny, CEO and founder of OPSWAT, offers a grounded take. He argues that AI just makes it easier for attackers to create and modify scripts targeting PLCs. The barrier to attacking industrial systems is falling. But his conclusion isn’t to chase better AI detection.

“The real lesson for me is still the same: stop giving attackers a path to the critical system in the first place,” he said. “And do not rely on antivirus and sandboxes to protect your data flow.”

That’s a sobering reminder. The fundamentals of ICS security—network segmentation, access control, patching—still matter most. AI may change the speed and sophistication of attacks, but it doesn’t change the basics of defense. For those managing critical infrastructure protection, the message is clear: assume your systems are targets, and act accordingly.

For more on how to secure operational technology environments, check out our guides on OT threat intelligence and PLC vulnerabilities.

Continue Reading

Infosecurity

EU weighs social media ban for under-13s as von der Leyen pushes ‘start date’

Published

on

social media ban

Brussels moves on kids’ screen time

The European Commission is weighing a continent-wide social media ban for children under 13, a move that would force platforms like TikTok, Instagram and Snapchat to verify ages far more strictly than they do today.

President Ursula von der Leyen told the Financial Times on Monday that she is considering a “harmonised EU-wide delay to social media” for kids under 13 who aren’t under a caregiver’s direct supervision. The idea: a legal start date, not just a terms-of-service checkbox.

“While ultimately it is up to parents to decide when children get their first smartphones, what we already have is a consensus that there needs to be a start date for the age children can join social media,” she said in a statement released Sunday.

Her proposal would give teens gradual access after turning 13, “depending on the proof given by the platforms that they are age-appropriate and safe for teenagers,” per the FT’s report.

Why age 13? And why now?

Thirteen isn’t arbitrary. Most platforms already require users to be at least 13, thanks to the US Children’s Online Privacy Protection Act (COPPA). But those rules are easily dodged — kids lie about birth dates, or simply tap “I’m old enough” without any verification.

The EU’s push would turn that soft restriction into hard law. Platforms would need to prove their services are genuinely safe for teens before granting access. That’s a heavy lift, and it’s exactly what von der Leyen is calling for.

“The status quo, a world where we continue to allow big tech unrestricted access to our children, will only consign another generation to more mental harm, addiction and misery,” she said.

The numbers behind the panic

Von der Leyen cited stark figures: European children now spend an average of four to six hours a day staring at screens.

“Six hours every day — this adds up to twenty years of their life,” she said. The line is dramatic, but it lands. Parents across the bloc are worried, and member states are feeling the heat.

She also drew a comparison that’s hard to argue with: society expects car manufacturers to include seatbelts and airbags. Why shouldn’t platforms be held to a similar standard of safety?

“It is clear we need age-appropriate restrictions to platforms,” von der Leyen said. “Because childhood will not wait. And once it is gone, we cannot give it back.”

Member states want more — maybe too much

Here’s the friction. Several EU countries, including France, Spain and Greece, have already imposed their own bans or are rushing legislation through their parliaments. Several are pushing for a cutoff of age 15, not 13.

Whether von der Leyen’s 13-threshold will satisfy those governments is an open question. Critics argue that 13 is too young, pointing to research on adolescent brain development and the particular vulnerability of mid-teens to social comparison and algorithmic rabbit holes.

The Commission’s proposal would also need to navigate the EU’s complex legislative machinery — a directive or regulation would require approval from both the European Parliament and the Council. That’s months, if not years, of negotiation.

What would enforcement look like?

That’s the trillion-dollar question. Age verification at scale is technically messy. Options include:

  • Government-issued ID checks (privacy advocates hate this)
  • Facial age estimation (creepy, but increasingly accurate)
  • Parental consent workflows (easily gamed, but a start)

The Commission hasn’t specified which method it prefers. But the phrase “proof given by the platforms” suggests the burden will fall on tech companies to demonstrate their systems work — not on regulators to police every signup.

What happens next?

For now, this is a proposal in search of a legal vehicle. Von der Leyen’s comments are a signal to member states that the Commission is listening, and a warning to platforms that self-regulation has run its course.

The political winds are blowing in one direction. With national bans already popping up, a patchwork of rules across the bloc is the real risk — which is precisely why von der Leyen wants a harmonised approach.

Whether 13 or 15 becomes the magic number, the era of unchecked teen social media use in Europe appears to be ending. The question is how quickly, and at what cost to privacy and innovation.

For parents, the takeaway is simple: the EU is finally treating childhood as something worth protecting from the attention economy. That’s a shift worth watching.

Continue Reading

Infosecurity

NCSC Tells Firms to Rein In Autonomous AI Before It Runs Wild

Published

on

Why the UK’s Cyber Spies Are Worried About AI Agents

The UK’s National Cyber Security Centre has a message for every organization building autonomous AI agents: assume they’ll misbehave. The agency published interim practical advice on August 20 for firms designing or operating agentic systems, and the tone is unmistakably cautious.

Several incidents involving AI models carrying out unsanctioned or unintended actions prompted the guidance. The NCSC admits formal guidance is still in the works and will eventually supersede this blog post. For now, this is the blueprint.

The advice builds on earlier NCSC work on securing agentic AI and lands as organizations scramble to build governance frameworks for systems that increasingly act on their own.

Sandboxing: The First Line of Defense

The NCSC’s core recommendation is refreshingly simple: figure out how much autonomy your agent actually needs before you let it loose. The agency wants firms to threat-model the agent’s prompts, tools, networks, and accessible services, then use those findings to decide which extra controls are necessary.

Don’t rely on the safeguards baked into the underlying model or agent framework. The NCSC warns these can be bypassed or prove insufficient in higher-risk environments. That’s a pointed message for teams who assume the AI vendor has it covered.

Network Controls That Say “No” by Default

For higher-risk deployments, the NCSC recommends running agents in robust AI sandboxing techniques and restricting access to only the resources required for a task. Network controls should deny connectivity by default wherever possible, with allowlists or service-aware proxies for anything the agent genuinely needs to reach.

The agency also advises separating agent execution, supporting infrastructure, and inference services where feasible. Why? Because agents can potentially discover configuration weaknesses or vulnerabilities in their own technical controls, creating a real risk of sandbox escape. That’s not paranoia — it’s a known failure mode.

Identity and Credentials: Shrink the Blast Radius

Every agent should get a distinct identity, the NCSC says, with credentials limited to what the task requires. Short-lived credentials are preferred. And here’s the kicker: organizations should treat API keys, OAuth grants, SSH keys, and authenticated sessions as part of an agent’s potential “blast radius.”

That framing is useful. If an agent goes rogue, those credentials are the difference between a contained incident and a full-blown breach. The less access each agent has, the smaller the damage it can do.

Human Oversight: Not Optional

The NCSC wants humans in the loop for higher-risk activity. That means named responsibility for agent operations, real-time monitoring, and the ability to intervene when unexpected behavior occurs. No more letting the AI run unsupervised and hoping for the best.

Agent activity should be logged and monitored as part of security operations and incident response. The agency also stresses the importance of being able to halt autonomous activity immediately — including restricting network access and communications with model infrastructure when necessary. A kill switch, essentially.

This aligns with broader industry efforts. The OWASP agentic AI security framework introduced earlier this year takes a similar maturity-based approach to managing these risks.

What This Means for Your AI Strategy

The guidance isn’t meant to scare organizations away from agentic AI. It’s meant to make them think before they deploy. The NCSC explicitly says the advice should evolve alongside the technology, and that organizations should regularly reassess whether the autonomy granted to agents remains proportionate to their risk tolerance.

That’s the key takeaway: autonomy is a privilege, not a default. Start with less, monitor closely, and scale up only when you understand the risks.

For teams building agentic systems, the checklist looks like this:

  • Assess required autonomy and threat-model before deployment
  • Run higher-risk agents in sandboxes with minimal resource access
  • Deny network connectivity by default; use allowlists
  • Give each agent a distinct identity with short-lived credentials
  • Maintain human oversight with real-time monitoring and intervention capability
  • Log everything and ensure you can halt activity instantly

The NCSC’s interim advice is a wake-up call. Autonomous AI is powerful, but it’s also unpredictable. Organizations that treat security as an afterthought will learn that the hard way. Those that follow this guidance have a fighting chance.

For more on securing AI systems, check out our coverage of AI governance best practices and autonomous agent risk management.

Continue Reading

Trending