When the AI sends you to the wrong download

You ask an AI assistant where to download a tool. You get a clear, helpful answer with the right product name and a link that looks fine. You click it, install — and you have just installed malware.

This is not theory. Active campaigns using this exact technique have already been observed in the wild.

What is happening

The safest way to download software has always been the same: go directly to the vendor's website if you know it. Searching is a fallback. Asking an AI is one step further removed again.

Attackers know this — and they know that more and more people now skip both the vendor site and the search engine, and just ask an AI chatbot "where do I download X?". So they have started feeding the AI ecosystem the same way they used to feed search engines: fake sites, planted content, and manipulated references.

The result: the chatbot gives you a friendly, confident answer — and one of the links in it points to an attacker-controlled site. The download looks like the real tool. It often even works like the real tool. But something extra gets installed in the background.

Why it works

The answer looks correct. The product name is right. The description is right. The tone is helpful and professional. Only the link is wrong — and it is wrong in a way that looks almost identical to the real one.

There is no urgent tone. No suspicious sender. No phishing markers. Just an AI being confidently wrong on a single line.

It is not just downloads — scripts too

The same trick works with code. You ask an AI for a script that does A. You get a script that does A — and quietly also does B.

The extra behaviour does not have to be large. A few lines that send data somewhere. A function with an innocent name that reaches out to a server you do not control. A small block of code wrapped inside something useful.

Security researchers have already demonstrated this. Attackers can plant malicious or misleading content in places the AI may later reference — public repositories, documentation, configuration files, or even hidden text embedded inside otherwise normal content. When someone later asks the AI for help, that planted content can influence what the AI produces, and the resulting code can contain something the user never asked for.

The script still works. It still does what you asked. That is what makes it hard to spot — and that is why pasting AI-generated code straight into production without reading it line by line is a real risk, not a theoretical one.

What to take from this

• Treat AI answers like advice from a stranger, not like a search result from a trusted source. Useful as a starting point, never as the final word.
  
  
• Always go directly to the vendor's website. If you know the address, type it yourself. If you do not, verify the domain through a trusted source first — not just an AI response or the first search result. Do not blindly trust download links provided by AI assistants. Verify the vendor domain yourself before downloading anything.
  
  
• Tell your users this. Most have no idea that AI answers can be manipulated. A short message in your normal channels goes a long way.
  
  
• Make sure your security stack inspects downloads — URL filtering, DNS security, and sandboxing catch many of these before the file ever lands.
  
  
• Read AI-generated code before you run it. Especially anything with network calls, file access, or credentials. If you do not understand a line, do not run it.
  
  
• Review your software installation policy. If users can freely install small utilities from anywhere, this attack works. If they cannot, it does not.
  
  

Bottom line

AI is changing how people find information — and attackers have already adapted. The fix is not new technology. It is the same rule we have always taught: go to the source you trust, do not let someone else hand you the link.

The difference is that the someone else is no longer a search engine. It is an AI that sounds like it knows the answer.

The police email that tries to scare you

From time to time a different type of scam starts circulating again.

This time the email claims to come from the police, Europol, or another law enforcement agency.

The message often accuses the recipient of serious crimes such as child exploitation or illegal online activity.

The goal is simple: to shock the recipient into responding.

The attack pattern

The victim suddenly receives an email that appears to be from a police authority.

The message often includes:
official logos
names of real officials
references to legal articles
a formal looking document attached as PDF

The email claims that investigators have identified illegal activity.

It usually demands a response within 24–72 hours.

The objective

Once the victim responds, the scam moves to the next stage.

The attacker may attempt to:
demand payment to “close the case”
request identity documents
collect personal information
continue the extortion

Why the technique works

Unlike many phishing attacks, this scam relies on fear rather than curiosity.

Being accused of serious crimes can trigger panic and cause people to respond quickly without verifying the message.

What makes this easy to identify

Law enforcement authorities do not send criminal accusations by email.

If the police were actually looking for you, you would not receive a PDF attachment.

Someone would knock on your door.

2025 version:(in Norwegian)
https://www.dt.no/skrekkbeskjed-for-mange-vil-arrestere-deg-umiddelbart/s/5-57-2550760

The email you were never supposed to see

In the previous posts I described attacks where victims first receive a large flood of emails, followed by a message from someone pretending to be IT support.

However, email flooding is also used in another way.

Sometimes the goal is not to contact the victim afterwards at all.

Instead, the attacker uses the flood of emails to hide a single message you are not supposed to notice.

The attack pattern

The attack again starts with a sudden wave of emails you never signed up for.

In the previous attack variants, this flood may consist of dozens or a few hundred messages — often enough to create confusion and stress.

But in this version of the attack the numbers are often much larger.

Victims may receive thousands of emails within a short period of time, sometimes several thousand within just a few hours.

This is typically caused by subscription bombing, where an attacker registers your email address on a large number of websites and mailing lists.

At first glance it may just look like spam.

But the real purpose is often different.

Somewhere inside those thousands of messages there may be one important email.

And that email is the one the attacker hopes you will miss.

The message you were not supposed to see

Hidden among the noise could be a notification such as:

• a password change confirmation
• a username or email change on an account
• a login alert from a service
• an order confirmation for a purchase you did not make
• a security alert from a service provider

If the victim does not see the message in time, the attacker gains a valuable window of opportunity.

For example, the attacker may:

• take control of an online account
• complete fraudulent purchases
• change recovery settings on a service
• gain persistent access to the account

Why the technique works

Humans are not good at processing thousands of messages at once.

When an inbox suddenly fills with hundreds or thousands of emails, most people focus on stopping the flood rather than carefully reviewing every message.

This is exactly what the attacker hopes will happen.

In reality, the only safe approach is often the most frustrating one: taking the time to carefully review the inbox and search for suspicious notifications.

If you suddenly receive thousands of emails within a short period of time, there is a real possibility that one of them contains a message you were not supposed to see.

Probably the most annoying version of the attack

Across the previous posts I described several variations of the same technique:

1. Spam flood + fake IT support contact (Teams or social media)
2. Spam flood + social engineering targeting personal accounts
3. Spam flood used to hide an important security notification

All of them start the same way: the attacker creates confusion and noise.

But for the victim, this third variant may actually be the most frustrating one.

Because the only reliable way to respond is often to spend time going through thousands of messages, searching for the one message that matters.

Exactly the message the attacker hoped you would never notice.


And if the attacker succeeded, that message is likely there.

Somewhere in the inbox is the notification that reveals what actually happened — a password change, a login alert, an order confirmation, or perhaps that your airline miles have been used or that someone just ordered ten new phones in your name.

Finding that email is often the first step to fixing the problem.

When attackers contact you on social media

In the previous post, I described a technique where attackers combine subscription bombing and fake IT support on Microsoft Teams to gain access to a victim’s system.

However, this is not the only variation of the technique.

In some cases the attack is directed at private individuals rather than employees in an organization, and the attacker uses social media instead of corporate collaboration platforms.

The attack pattern

The beginning of the attack often looks very similar.

The victim suddenly receives a large number of emails they never signed up for.
This is typically the result of subscription bombing, where the victim’s email address is registered with hundreds of websites and mailing lists.

The goal is to create confusion and stress.

Unlike the corporate scenario, the attacker may already know that the email address is connected to personal accounts, such as:

• Facebook
• Instagram
• LinkedIn
• other social media platforms

Shortly after the spam flood begins, the attacker contacts the victim through social media messaging instead of tools like Teams.

The attacker might claim to be:

• platform support
• account security staff
• technical support
• someone who noticed suspicious activity on the account

They then offer to help fix the problem.

The objective

Just like the Teams-based variant, the attacker will often try to convince the victim to:

• install remote access software
• share login credentials
• approve suspicious login attempts
• disable security protections such as two-factor authentication

Once the attacker gains access, they may attempt to:

• take over social media accounts
• access private messages and data
• run scams from the victim’s account
• attempt password resets on other services linked to the same email address

The same scam — different channel

In many ways, this is simply another evolution of the classic fake tech support scam.

The difference is that modern attackers often create a real problem first — such as a spam flood — before contacting the victim and offering help.

The communication channel may change:

• phone calls in the past
• Microsoft Teams in corporate environments
• social media messaging for private individuals

But the core technique remains the same:

Create confusion → Offer help → Gain access

When attackers call on Teams

Suddenly your inbox starts filling up with hundreds of newsletters you never signed up for. 
Minutes later, a Teams message appears from “IT Support” offering to help.

This is not a coincidence!

A social engineering technique observed in several incidents combines two simple elements: large volumes of spam and fake IT support.

The attack typically begins when the victim receives a sudden flood of spam emails.
This is often the result of so-called subscription bombing, where the victim’s email address is registered with hundreds of online services and newsletters.
The result is an inbox that quickly fills with confirmation emails, newsletters, and other automated messages.

Shortly after the spam flood begins, the attacker contacts the victim through a collaboration platform such as Microsoft Teams, pretending to be from the organization’s IT department.
The attacker claims they have noticed the unusual email activity and want to help resolve the issue.

To “fix the problem,” the attacker asks the user to start a support session using a remote administration tool. The tool used is often Quick Assist, which is built into Windows, but tools such as AnyDesk, TeamViewer, or similar may also be used. Because the user is already experiencing a real problem — a spam flood in their inbox — the request may appear legitimate.

Once the attacker gains access to the system, several actions may follow depending on the objective of the attack.

Examples include:

• deployment of ransomware
• theft of files or sensitive information
• credential harvesting
• lateral movement within the network
• establishing persistent access to the system

The technique works because it exploits human behavior rather than technical vulnerabilities.
By first creating confusion and stress through the spam flood, the likelihood increases that the user will accept help from someone claiming to be IT support.

---

How to Reduce the Risk

In many environments, messages from external users in Microsoft Teams can be clearly labeled with indicators such as External, Guest, Unverified, or similar warnings.

These indicators help users recognize that the message does not come from an internal colleague or the organization’s IT department.
If someone claiming to be internal IT support contacts a user via Teams, these indicators should always be checked.

Organizations should ensure that such labels and warnings are properly configured in Teams so that users can more easily distinguish between internal and external communications.

If this has not already been reviewed or implemented in the environment, it may be advisable to assess the current configuration and procedures.

In many ways, this is a modern version of the classic “fake Microsoft support” phone scam.
The difference is that attackers now create a real problem first — such as a spam flood — before offering to “help” fix it.

Christmas is a time when attackers try their luck

Christmas is a period when many people are off work, and some are a bit deep into the holiday season. That can mean fewer eyes on logs, alerts, and anomalies. That is exactly when attackers like to test your defenses.

So here is a simple reminder: Run a best practice assessment (BPA) on your Palo Alto Networks firewall now, and make sure the expensive, capable box is actually being used.

I am sharing my BPA screenshots too. My score is OK, but it is worth saying this is easier in a smaller environment. In my home lab I run 22 VLANs, around 100 devices, and 162 security rules, which means fewer dependencies and less legacy to clean up than in a large enterprise.

Feature adoption

Best practices

The point still stands: Aim for at least 80% on both Feature adoption and Best practices. If your numbers are low right now, it could be exactly your organization that gets hit over Christmas.

Quick wins to do before the holidays on a PA firewall

• Ensure security profiles are attached to all security rules.

• Confirm logging is enabled for all security rules.

Patch and reboot

This is a general tip, not PA-specific, and it is a simple example of how small steps can meaningfully improve security. Patch the things you have been postponing. If your PC is sitting there asking for a restart, do it. That “restart required” message is often the final step of a security update. It feels small, but imagine if that one reboot is the little thing that actually saves Christmas, and lets everyone enjoy the holidays instead of firefighting in the days after.

Wishing you a peaceful, secure, and attack-free Christmas.

Denial of comfort

When a loudspeaker becomes an attack vector

Smart speakers like Alexa, Google Assistant, Siri and Sonos offer a lot of convenience, but they also introduce a physical attack surface: sound.

If a device executes whatever it hears, anyone who can inject a command into the microphone – even with a megaphone outside an open window – can try to interact with your digital life. Before you rip out your smart home setup, let us look at what can actually happen.

What can actually happen from outside?

In practice, a “megaphone attack” is far more likely to cause noise than a real break-in, but the methods are evolving.

High probability: noise and nuisance

In many setups, media and volume commands require no authentication. If a speaker is within earshot of an open window and linked to a group like “All speakers”, a shouted command such as:

“OK Google, play Gummy Bear on Spotify, all speakers, volume 100 percent.”

“Alexa, set volume to 10 on all speakers.”

“Hey Siri, play Gummy Bear on Spotify at full volume.”

...can realistically:

• start playback across the house

• push the volume to the maximum

The worst-case scenario here is not a data breach, but a denial of comfort. An unwanted Gummy Bear concert at 03:00 is frustrating, but it is not a full system compromise.

The silent threat: inaudible frequencies

It is not always about shouting. Researchers have demonstrated inaudible attacks (often cited in papers like DolphinAttack), where commands are modulated onto ultrasonic carrier waves (e.g., above 20 kHz).

While the human ear cannot hear these frequencies, the hardware in many smart speaker microphones creates a non-linear reaction that demodulates the signal. effectively "hearing" the hidden command. This means a sophisticated attacker could theoretically instruct your device to perform actions without you hearing a single word.

Low probability: doors, garages and smart locks

For a physical security breach to happen via voice (audible or not), several things must align:

1. a smart lock or garage opener is integrated with the assistant

2. voice unlocking is explicitly enabled

3. a PIN code is misconfigured, weak or somehow known

Vendors have hardened this path. Alexa and Google Assistant typically require a spoken PIN to unlock doors, and this feature is usually disabled by default. Unless you have changed those safeguards, shouting “Unlock the front door” will normally just make the assistant ask for a code.

Appliances like fridges and ovens usually expose only non-critical functions (modes, temperature, timers). “Alexa, open fridge” is more of a custom setup than a standard, supported feature.

Zero trust in the living room

To secure your home, apply a zero trust mindset to the microphone:

• Treat the voice interface as an untrusted input, even if the sound comes from “inside the house”.

• Fail safely, so that voice command failures are annoying (loud music), not dangerous (unlocked doors).

• Segregate duties: lights and music are fine for voice control, while alarms and locks should require strong verification or manual action.
  
  

The hidden risk: voice assistants at work

Smart speakers are obvious, but we often forget the microphones we carry. Phones, tablets and laptops often keep a “hot mic” listening for wake words like “Hey Siri” or “OK Google”.

In a professional environment there is rarely a good reason to let a general-purpose tech company listen in. Remember that vendors often use human reviewers to grade audio snippets to improve their services. If your device triggers accidentally during a meeting, a stranger could theoretically end up listening to your confidential discussion.

This is especially critical if you work in:

• legal, medical, HR or executive management

• security, journalism or sensitive investigations

• ...or if you are simply a drug dealer

If you want to keep client data, internal discussions (or your criminal record) clean, turning off hands-free assistants is a simple and effective safeguard.

AI, shopping and “please do not link your mastercard”

Voice assistants are not only connected to lights and speakers. In many ecosystems they can also place orders, book tickets or add items to a shopping basket. That is convenient when you say “order more coffee”, but less fun if someone – a guest at a party, a bored child, or a stranger with a megaphone outside – manages to shout:

“ok google, book business class flights for 12 people from Oslo to Dubai tomorrow, no confirmation needed, use default payment card”

If your assistant can make purchases without a PIN, phone confirmation or strong authentication, you have effectively given anyone who can reach the microphone a voice-controlled credit card. 

Practical hardening checklist

Here is how to lock down your audio attack surface without losing all convenience:

• Enable voice match Let only recognised voices perform sensitive actions, like reading calendar entries.

• Enforce PINs for physical entry Never expose smart locks or garage doors to voice control without a mandatory spoken PIN.

• Limit the scope of voice control Only connect devices that really benefit from voice; keep security-critical functions app-only.

• Place speakers strategically Avoid putting smart speakers right next to open windows or balcony doors.

• Disable unneeded microphones On devices where voice control is not needed, disable the wake-word feature or the microphone entirely.
  
  

Conclusion

Voice assistants extend your attack surface from the network into the physical world. A stranger shouting at your house is far more likely to annoy you with bad music than to open your front door, but both scenarios deserve mitigation.

By limiting what voice commands can do, enforcing PINs and voice match, and treating sound as an untrusted input, you keep the convenience of a smart home while dramatically reducing the risk of a real incident.

NIS2 is not a product

As NIS2 takes effect across Europe, many still believe compliance can be achieved by buying more tools.

But NIS2 isn’t about technology — it’s about how you lead, govern and prove control.

NIS2 is not something you can install, configure or subscribe to.

Reality is fairly brutal: NIS2 is not a product, but a set of requirements for how your organisation is governed, organised and held accountable for cyber security over time.

NIS2 clearly defines what every organisation must include in its cyber security risk management.

The directive spells out these seven areas as the foundation for compliance:

(a) policies on risk analysis and information system security;
(b) incident handling;
(c) business continuity, such as backup management and disaster recovery, and crisis management;
(d) supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers;
(e) security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure;
(f) policies and procedures to assess the effectiveness of cybersecurity risk-management measures;
(g) basic cyber hygiene practices and cybersecurity training;

You cannot “buy” policies, risk analysis or governance – you have to decide how you work.
You cannot outsource responsibility for incident handling, continuity or supply-chain risk – only execution.
You cannot claim NIS2 compliance if you never assess whether your measures are effective or if you skip basic cyber hygiene and training.

However, technology and products can absolutely help you achieve these requirements – if used the right way.
Firewalls, XDR, SOC services, vulnerability management, identity platforms and backup solutions are all powerful tools, but they only make sense when mapped to clear governance, roles and processes.

Don’t see NIS2 as a burden — use it as leverage.

For once, the law puts accountability where it belongs — with top management.
That means IT has a clearer mandate to demand the resources, structure and time required to meet these obligations.

NIS2 isn’t a problem. It’s your chance to get security taken seriously.

If someone tries to sell a “complete NIS2 solution” in a single product, this A–G list is the reality check:
NIS2 is a governance and accountability framework first — technology only adds value when it supports these obligations.

Use NIS2 as the push to build stronger governance, better processes and a culture where security is part of how you operate.

7-layer filtering

If you still believe your port-based firewall is enough, you probably already have unwanted guests on the inside.
Firewalls that only look at IP and port stopped being “secure” more than a decade ago.

CIS control 13.10 is about inspecting and controlling traffic at all layers, not just by ip and port. A modern NGFW is expected to understand which app and port are in use, which source user is behind the session, and which url is being accessed.

Example of 7-layer visibility: decrypted HTTPS session identified as netflix-base, full URL, user, and rule context logged.

Classic firewalls ask “source, destination, port – allow or deny?”. That mindset belongs to 2010. If your firewall still works that way, it is not protecting you — it is only routing with a false sense of security.

Attackers hide perfectly inside HTTPS and “normal” traffic. Everything looks fine on TCP 443 until you look deeper and realize what is actually happening. You cannot defend what you do not inspect.

Way too many network admins still choose not to log internal traffic, disable application inspection, and leave url filtering turned off between trusted zones. The usual excuses are performance, “too much noise,” or the illusion that internal traffic can be trusted — but the cost of missing what happens inside your own network is far higher. Modern firewalls have long been capable of full visibility — yet many are still configured like it’s 2010.

And yes — some even buy a brand-new NGFW and simply import the old configuration straight into it. That solves nothing. Shit in, shit out.

Internal traffic is where misuse, misconfigurations, and lateral movement begin. Without logs, you lose your early warning system. You cannot claim zero trust if your internal traffic is invisible.

If a workstation suddenly calls an internal url like /admin/export-users, /admin/backup/download, or /api/v2/internal/payments, that is not noise. That is a clear signal that something is wrong – and you need to see it, alert on it, and react.

Application visibility has been available for more than 15 years. There is no reason to still run a firewall that only understands ports.

Log everything — especially inside your own walls. Today’s threats live there.

Footnote with attitude:
The application field should never be “any.”
The port field should never be “any.”
If the app is, for example, ssl or web-browsing, a URL category must be applied.
If you leave Antivirus, Anti-Spyware, Vulnerability Protection, URL Filtering, and WildFire profiles empty, you are not demonstrating a Next-Generation Firewall.

Example from https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClWZCA0

And honestly — come on Palo Alto Networks.
You build one of the best firewalls on the planet, but your own documentation screenshots still show “any” on port and app, with no security profiles applied.
How about showing examples that reflect how an NGFW should actually be configured?

New EDL lists from my honeypot

edl.mrlogg.no/

A simple honeypot runs on a public IP that is not listed in DNS and not associated with any domain/FQDN.
Traffic to ports 22 (SSH) and 3389 (RDP) is logged, deduplicated, and published as external dynamic lists once per day.
If you think like me—that sources probing SSH/RDP on such an unadvertised IP are “bad” by default—you may want to block them for all inbound traffic.

I see no reason they should reach vpn.company.com, portal.company.com, mail.company.com, api.company.com, or *.company.com.

Links

• edl.mrlogg.no/port22.txt

• edl.mrlogg.no/port1433.txt

• edl.mrlogg.no/port3389.txt

• more to come..

Format

• One IPv4 per line, no CIDR, no comments

• Lists are overwritten on each daily run

Disclaimer

• Use at your own risk. False positives are possible (e.g., research scanners)

• Treat this as a signal, not a verdict

Goal

• Reduce brute-force attempts and malicious port scanning

• Reduce alert noise and log volume

Updates

• More lists may be added; check edl.mrlogg.no for new .txt files

Port info

Port	Service	Typical use	Why targeted
22	SSH	Remote login and file transfer	Common target for brute-force on credentials
23	Telnet	Remote console access (legacy)	Sends credentials in cleartext; easily abused
25	SMTP	Mail transfer between servers	Scanned for open relays and spam abuse
1433	Microsoft SQL	Database connections	Searched for exposed databases and weak creds
3389	RDP	Windows remote desktop	High-value target for brute-force and exploits
5555	IoT services	Device debugging and management	Often exposed on insecure IoT devices
5900	VNC	Remote desktop control	Brute-force and discovery of open controls
8080	HTTP / proxy	Web apps and admin interfaces	Scanned for misconfigurations and panels
9100	Printing	Network printer raw printing	Abused for spam-print, DoS, or printer exploits

Feedback and requests are welcome. Contact me on LinkedIn

Phishing simulation that actually teaches something

 

Everyone can be fooled. The goal is to build good habits, not to expose people. Everyone — including experienced IT staff — can fall for targeted phishing; the goal is to reduce click rates year over year. Ten fewer clicks in 2026 than in 2025 can represent a major improvement and a measurable reduction in risk.

Start with simple exercises that include clear warning signs to build confidence. Conduct these simple simulations regularly – they create awareness, and those who click on them should be prioritized for additional training. When a small group keeps clicking repeatedly, that’s where education needs to start. These users often highlight where communication, awareness, or process gaps still exist. This is exactly where things tend to go wrong in real situations.

Gradually increase the realism by removing the obvious errors and using internal context. Follow up repeated clicks with quick, friendly 1:1 guidance and short micro-training, not sanctions.

There’s no real value in designing a simulation that fools 99% of employees. People might learn something from it, but the result is usually frustration and low motivation. Most users can detect even highly convincing phishing attempts – if they get just a couple of minutes of proper guidance first.

A practical example that works well in training sessions:
An employee receives an email that appears to come from a logistics supplier. One wrong click opens a form for “account verification.” It looks harmless, but behind the form a small script installs a remote access tool. Within two hours, the attacker has reused the same credentials to reach a server containing customer information. It all started with one click – not with bad intent, just a moment of inattention.

The point isn’t to scare anyone, but to show how little it takes – and how much safer things become when emails are reported instead of clicked.

To help people spot them in practice, here are some common warning signs:
• Unknown or mismatched sender: The email address doesn’t match the company name or domain.
• Suspicious link preview: The destination domain is different from what the text shows.
• Requests for passwords or codes: No legitimate service will ever ask for credentials by email.
• Urgent tone or threats: Messages pushing immediate action often aim to trigger panic.
• Unexpected or suspicious attachments: Files you didn’t ask for, especially with names like “urgent_invoice.doc” or “security_update.zip.”
• Strange or incomplete signature: Missing name, title, or contact info can signal a fake sender.
• Unusual time of day: Emails sent late at night, during weekends, or holidays can be suspicious.
• Unfamiliar tone or wording: The writing style doesn’t match how the person usually communicates.
• Generic greeting: “Dear user” or “Hello colleague” instead of your actual name.
• Inconsistent branding: Logos, colors, or formatting that look slightly off.
• Email marked as “external” but looks internal: A trick often used to bypass trust filters.
• Unusual requests: Asking for gift cards, wire transfers, or sensitive internal data.

Spotting just one of these warning signs early can prevent a full-scale incident.

Phishing awareness is part of Zero Trust in practice — always verify, even if the sender looks familiar, and make reporting part of everyday security hygiene.

Building awareness isn’t about perfection — it’s about progress. Every report instead of a click makes the organization stronger and more resilient.

Fake verification scams: why “press Windows + R” is a trap

 

Introduction

No legitimate site asks you to press Windows + R and paste commands. This post explains the risk and how to prevent it.

What it is

Fake verification pages mimic CAPTCHA or security checks. They tell users to press Windows + R, paste a command, and press Enter — executing code copied to the clipboard.

How the attack works

The page copies a command to the clipboard. When pasted into Run, it executes via CMD or PowerShell and often downloads malware, opens a reverse shell, or steals credentials.

Why it succeeds

It abuses trust and urgency. Users think Run is harmless, the page looks official, and many endpoints still allow local command execution.

Mitigations (technical level)

• Remove local admin rights.

• Limit local execution with least-privilege access.

• Block unknown or unsigned scripts with AppLocker or similar.

User training

• Never paste commands from webpages into Run, terminal, or PowerShell.

• Communicate this rule via your normal channels (meeting, chat, email).

Good enough cyber security – or do you want to be among the best?

 

A lot of people say they have good enough cyber security.
But in cyber security, good enough is often the first step toward not enough.

Is it an antivirus that scores average in tests, or one that ranks in the top three?
Is it using multi-factor authentication only for management, but not for the operations team?
Or a firewall that allows everything, just to make things work?

Many still believe that no one is interested in them.
But most attacks aren’t targeted – they’re automated.
They look for weak spots, and good enough is often exactly that.

We see it every week: an unpatched system, an old password, or an open rule that was never reviewed.
It works – until the day it doesn’t.

Think about it this way:
Would management say it’s fine to show up at work in swimwear twice a year,
while everyone else wears suits the rest of the time?
Probably not.
Dress code is 100% – not good enough.

Security should be treated the same way.
You either have control, or you don’t.
Good enough doesn’t protect you as well as it should – it only feels comfortable until something happens.

Threat actors don’t stop because you’re average,
but they might move on when you’re better than your neighbor.

The best organizations treat security as a competitive advantage.
They build trust, protect value, and show that quality doesn’t stop at minimum compliance.

Security isn’t about being perfect – it’s about getting a little better every week.
Attackers only need one weakness.
Your job is to close every one of them –
just like you lock every door when you leave the office, not nine out of ten.

So next time someone says good enough, ask:
Good enough for whom – you, or the attacker?

And remember: you don’t need big projects to improve.
Start small – update one system, tighten one firewall rule, remove one unnecessary access.
Do it every week.

Or take inspiration from a few simple CIS principles:

• Know your assets. You can’t protect what you don’t know exists.

• Keep systems updated. Most attacks exploit known vulnerabilities.

• Limit access. Give only what’s needed – that’s how least privilege and Zero Trust start.

• Log and monitor. What you don’t see, and don’t log, won’t be detected or stopped.

Real security isn’t built in a single project.
It’s built through small, consistent actions – logged, learned, and improved.
One step, one log, one improvement at a time.

And one more thing:
Don’t just choose the cheapest antivirus, firewall, or SOC provider.
Run your own tests and check the quality before you trust it –
unless you already know someone who has tested it thoroughly.

Good security isn’t about saving money; it’s about knowing what actually works.

Why IT departments should not sit in open-plan offices

 

Open-plan offices have become a trend in recent years. The idea is to promote collaboration, flexibility, and communication. And there is no doubt that this setup has benefits:

• collaboration becomes easier, since you can quickly ask the colleague next to you

• knowledge sharing happens naturally and informally

• it builds team spirit and a sense of community

• communication flows faster, and problems can often be solved on the spot

For many departments this can work well. But for an IT department, an open-plan office is directly risky.

The risks of open spaces

IT staff handle information that is critical to the business: system configurations, logs, network diagrams, and security incidents. When these tasks are carried out in an open office environment, the risk of unauthorized access increases significantly.

This is particularly important for functions such as the CISO or the Security Operations Center (SOC), where staff may be dealing with ongoing incidents, threat intelligence, or forensic data. Such information should never be visible or overheard in an environment where guests, contractors, or even other employees without clearance can pass by.

The classic example is “shoulder surfing” – someone glancing at sensitive content on a screen. Equally problematic is the risk that confidential conversations are overheard. 

Another often overlooked risk is sound leakage: in open-plan offices, a customer on the phone may also hear conversations from nearby desks, unless very advanced headsets with strong noise isolation are used. This means sensitive discussions between colleagues can unintentionally be shared with external parties.

ISO 27001:2022 – why open-plan is a problem

ISO 27001:2022 highlights several controls that all point to the same issue: sensitive information must be protected from unauthorized access. Open-plan offices make this nearly impossible.

• Physical security perimeters

• Physical entry controls

• Clear desk and clear screen

• Information security in supplier relationships

Real-life scenarios show how quickly security can fail in relation to these controls:

• a visitor waiting for a meeting can easily photograph notes, diagrams, or printouts left on a desk

• a contractor or job candidate passing by may glimpse a screen just as someone opens an attachment, without realizing the first page contains confidential information

• when an IT employee locks their computer to get a coffee or use the restroom, they may leave documents on their desk – one quick smartphone photo is enough to capture that information permanently

• suppliers or service providers moving through the office may unintentionally gain visibility into data they should never have access to

It is also worth noting that other standards and frameworks – such as GDPR, NIS2, NIST, CIS Controls, and NSM grunnprinsipper (Norway) – point in the same direction, emphasizing the need for physical protection of sensitive information and controlled access to workplaces.

Other departments should also reconsider

It is not only IT that should think twice about open-plan setups. Departments handling sensitive information face similar risks, for example:

• HR – managing personal data, employment contracts, and health-related information

• Legal/Compliance – working with confidential documents and internal investigations

• Finance – handling accounting, banking, and budget data

• Executive/Strategy – discussing mergers, strategic plans, or other confidential information

• Research & Development – working on products, designs, or innovations that may be patented or involve intellectual property

• Customer support – handling customer records, tickets, and sometimes payment details

• Project teams for mergers & acquisitions – where leaks can have major financial consequences

All these functions risk exposing information if their workspaces are too open and accessible.

Real-world observations

When walking the streets of Oslo or Bergen, I often see offices on the ground floor with large windows facing the street. It is surprising how easy it is to see what people are working on. With today’s smartphone cameras, it takes no effort to take pictures or record video from the sidewalk – or even from a hotel room across the street.

The question is: do these companies think about security at all? It is frighteningly easy for outsiders to gain insight into customer data, accounting systems, or even online banking screens.

Conclusion

Open-plan offices can bring real benefits such as collaboration, flexibility, and stronger team dynamics. But for departments dealing with sensitive information – especially IT – the risks outweigh the benefits.

An IT department should therefore never sit in an open-plan office if guests, contractors, or even passersby can gain visibility. The same applies to HR, Legal, Finance, R&D, Customer Support, and Executive functions.

Physical segregation is not only common sense – it is a requirement for ISO 27001 compliance and a cornerstone of a strong security culture.

When documentation becomes the breach

 

I love documentation—and I recommend documenting a lot. It creates memory, clarity, and resilience. But attackers love it too. Over time, spaces like confluence and sharepoint collect shortcuts, “temporary” exceptions, and helpful screenshots. Alone they look harmless. Together, they can map how to step around controls.

👀 What attackers actually use

• Notes that describe how to “temporarily” bypass checks

• Mentions of shared or test accounts used “for convenience”

• Hints about remote access, allow-lists, or quick openings “for support”

• Screenshots that reveal settings, approval flows, or who to ask

• Exported lists of users, systems, or internal locations

• Attachments with no owner, no classification, and no review date

• Links set to “anyone with the link,” often without an expiry

• Scripts, runbooks, and “how-to” guides that include sensitive internal details

🧩 Why this keeps happening

• Helpful people share broadly so others aren’t blocked

• “Just for now” files never get cleaned up

• MFA is not enforced

• Shared users survive because they’re easy

🔐 Simple habits that help (zero trust)

• Put things where they belong: secrets in a password vault, code in source control, configs in the right system—not in the wiki

• Use SSO and MFA for confluence and similar tools; limit or disable local passwords where the platform supports it (especially for admins)

• Grant access to named groups, not “anyone with the link,” and give links an expiry

• Require an owner, purpose, and review date for sensitive pages and attachments

• Avoid screenshots of sensitive settings; document outcomes instead

• Review sharing regularly and close what’s no longer needed

✅ Bottom line: Wikis should explain how we work—not how to work around controls. Keep them clean, and zero trust becomes a daily habit, not a slogan.

Without IT asset management, cyber security becomes guesswork

 

🙏 Begin your IT security journey at the beginning, not in the middle.
Too many organizations jump straight into firefighting—patching vulnerabilities, responding to incidents, and buying new tools—without ever laying the foundation. The foundation is always IT asset management (ITAM). Without it, everything else is largely built on assumptions.

💾 Think about it: you wouldn’t order a backup server without knowing how much or what data you need to protect. And you wouldn’t buy a firewall without knowing what it is supposed to defend, or how much traffic it must be able to handle. The same logic applies to cyber security as a whole—you must start with ITAM, or everything else becomes guesswork.

👀 You cannot protect what you cannot see.
Without updated and reliable ITAM, risk assessments quickly turn into theory detached from reality. Many organizations say they have X critical systems, and that sounds reassuring. The problem is the Y systems they don’t know about—the ones set up by someone years ago, without documentation, still running in the background, and still connected to the network. X represents the assets you know and track, while Y represents the shadow IT: the forgotten, hidden, or undocumented systems that pose just as much risk, if not more.

⚽ It is a bit like football: to build a strong team, the coach must know exactly which players are on the field, their positions, and their strengths. Only then can he create a winning strategy. ITAM works the same way—without a complete view of all systems, you cannot build a secure IT environment that functions as a well-organized team.

🌐 Whether the environment is on-premises or in the cloud makes little difference; the challenge is the same.
You must know what you have before you can assess whether it is secure or not.

⚠️ At minimum, every device with an IP address must be accounted for.
But the real goal must be to cover all assets—including OT equipment and sensors that may not have their own IP address yet still impact operations and security. Without this broader view, the inventory remains incomplete and the risk picture distorted.

🔑 Frameworks agree:

• Norway’s NSM grunnprinsipper call for complete and updated asset overviews.

• ISO 27001 requires organizations to identify, classify, and manage assets throughout their lifecycle.

• The CIS framework starts with Inventory and Control of Enterprise Assets as Control 01—the very first step toward building a secure baseline.

🚢 Maritime regulations agree too:

• IMO 2021 requires cyber risk management to be integrated into the ship’s Safety Management System (SMS). A key part of this is maintaining an up-to-date inventory of all systems and assets as the basis for risk assessment.

• IACS UR E26 (mandatory for newbuilds contracted from July 2024) demands a complete inventory of hardware and software, along with network diagrams and lifecycle documentation, to ensure cyber resilience of ships.

✅ The message is clear: without ITAM, cyber security is reactive and based on assumptions. With ITAM, zero trust becomes possible, measurable, and sustainable.

PANOS 12.1 ORION installation on PA-440 and Panorama

PANOS 12.1 ORION installation on PA-440 and Panorama

Bad start on the Panorama for me:
Failed to create required free space. Free space: 2778 MB, Required space: 3717 MB


Found a guide for cloning Panorama disk to a new and larger disk. Only used 15 minutes to clone and remove the old disk.
https://docs.paloaltonetworks.com/panorama/10-2/panorama-admin/set-up-panorama/set-up-the-panorama-virtual-appliance/increase-the-system-disk-on-the-panorama-virtual-appliance/increase-the-system-disk-for-panorama-on-an-esxi-server#id27229f7c-6701-4fef-9ad7-cb630ea5cbcb

 

Guide worked perfect and I booted up Panorama with free space available.




PA-440:

Reboot take about 15 minutes.
....and some more waiting time before login is up and running.

Welcome to PAN-OS 12.1!

With this release, Palo Alto Networks extends and improves your security posture with our innovative approach. PAN-OS 12.1 provides passwordless authentication capabilities, additional quantum protections, expanded Device-ID capabilities, decryption enhancements, and more. Highlights include:

Passwordless Authentication for Kerberos Protected Applications—Enables your Palo Alto Networks firewall to act as a Kerberos Constrained Delegation (KCD) agent. This feature allows seamless access to enterprise applications using Kerberos authentication, eliminating the need for users to repeatedly enter credentials. Enhances security by reducing password-related vulnerabilities and improves productivity by streamlining access to multiple Kerberos-protected applications.

Quantum Key Distribution (QKD)—Provides protection for VPN key exchanges by using the ETSI GS QKD 014 standard, QKD, to provide a set of standardized API calls that enable a PAN-OS firewall to communicate with and request symmetric encryption keys from a QKD Device. The PAN-OS firewall acts as the secure application entity (SAE) device and makes API calls to the QKD device, called the key management entity (KME). Depending on the QKD vendor’s implementation, you can use TLSv1.3 to secure the key generation process.

Advanced Device-ID—Enables more granular and precise device-based policy recommendations by enhancing the existing Device-ID functionality. Advanced Device-ID enables the creation of least-privilege access policies by creating device object groupings based on device attributes. With Advanced Device-ID, you can now create more complex Device-ID objects by matching grouping criteria using multiple asset categories and attributes (10x more than before) such as asset type, device profiles, operating systems, site, location, subnet, risk, internet access, and user tag to match assets and enforce security policies based on changing security posture.

Post-Quantum Cryptography (PQC) SSL Support for PAN-OS Management—Supports PQC in TLSv1.3 for administrative access to firewalls and Panorama and facilitates a smooth adoption of PQCs as a proactive defense against PQC threats. This feature prioritizes maximum interoperability and adaptability to future PQC updates. You can also generate self-signed certificates with the NIST-approved digital signatures, ML-DSA and SLH-DSA (based on SPHINCS+), for experimental use as the industry works toward a standard approach for PKI certificates.

Post-Quantum Cryptography (PQC) Cipher Support for TLSv1.3 Inline Decryption—Enables PQC cipher support in TLSv1.3 for SSL Forward Proxy and SSL Inbound Inspection, as well as the decryption mirror and Network Packet Broker features. You can now use PQC preferred ciphers in the decryption profile either for client session, server session, or both. This flexibility allows for post-quantum migration as either the client or server side could be first to adopt PQCs and this feature supports cipher translations across the client and server sessions of the decryption proxy. You can also elect to negotiate Standard (ML-KEM) and/or Experimental (BIKE, Frodo, HQC) ciphers to support NIST and EU requirements allowing for Crypto Agility of ciphers as required.

Decryption Simplification—New options have been added to decryption functionality to simplify certificate verification and log analysis. For example:

Use the new Bypass Server Certificate Verification option in decryption profiles to disable the verification of server certificates, so that the firewall can decrypt outbound SSL traffic from an internal client to the web. This ensures the availability of websites and applications without compromising deep packet inspection for threats during SSL Forward Proxy sessions when servers present incomplete or invalid SSL certificates.

More easily analyze log entries and troubleshoot decryption issues using the new columns provided. For example, Decryption Status lists the reason a session was or was not decrypted, whether by failure or design. In addition, new and existing columns that concern one side of a decrypted session are labeled with client or server if conditions apply to only one or the other.

Zero Touch Provisioning (ZTP) for Cellular—Enables automated deployment and configuration of NGFW in remote locations with limited connectivity or lacking traditional wired connections using cellular interfaces. With the expanded support for cellular connections, ZTP now supports multiple connectivity scenarios, including cellular-only, ethernet-only, or both to provide the flexibility to adapt to various network environments. The feature is designed to work with current and future 5G-enabled platforms, ensuring long-term value and adaptability as your network evolves.

For descriptions of the new features, associated software and content releases, changes in default behavior, and other release information, refer to the PAN-OS 12.1 Release Notes.

HA/failover with one NGFW in PANOS 12.1.2 and one NGFW in 11.1.10-h1 worked in my test.

I really like the new report, telling me what I need to fix, and how!

Certificates seems to have an update, great news, maybe SSL decrypt works better now.

New AI Security profile, this can be fun.

 

Was hoping for more SD-WAN updated, didn't find anything so far.