Forem: Nicolás

Basic protections for your S3 buckets

Nicolás — Thu, 08 Jan 2026 20:12:10 +0000

S3 is one of the most popular storage services in AWS due to its simplicity. You can easily store large amounts of data for multiple purposes at a relatively low cost.

Regardless of your use case, I imagine you want your precious data to be stored securely, not only because of the trouble you could face with regulators, but because it's simply the right thing to do.

Today, I am going to talk about some basic safeguards that you can implement in S3 to help secure your data with no extra cost.

Let's start with a classic one.

Encryption

Encryption is the process of taking readable information, like your secret master plan that will make you rich, and converting it into unreablable format so that only authorized parties can access it.

I won't bore you with technical details but the key point is that encryption is important.

Most encryption you will see fall into two categories: at rest, and in transit. You may also hear about encryption in use, but that one is out of scope for this article.

Encryption at rest

In simple terms, encryption at rest deals with data that sits idle, waiting in your storage to be used. You can think of encryption at rest as having a safe where you store a top secret notebook, only authorized parties, the ones that know the code, can open the safe and access your data.

There are two main encryption methods in S3:

Server-side -> AWS encrypts the data for you before saving it on disks
Client-side -> You encrypt the data before uploading it to S3

The good thing is that buckets have encryption at rest configured by default. That way, all the objects you upload will be using Server-side encryption with AMazon S3 managed keys (SSE-S3). ALl this will be transparent to you and free of charge.

For most use-cases, SSE-S3 will be more than enough, but if you want more control, you can opt to encrypt your data using a KMS key you control.

Encryption in transit

The other encryption category we mentioned is encryption in transit. This one is in charge of protecting the data as it moves around, like when it moves from AWS to your devices as you download it.

Encryption in transit is important to guarantee the secret of communications. If there was no encryption, anyone that intercept your network traffic could read into your emails and know what your last purchase at Amazon was.

This type of encryption is achieved using asymmetric encryption, which relies on a pair of keys, a public key and a private key, to establish a secure channel between two parties for sharing information.

Think of a mailbox that anyone can drop letters into, but only the owner can open.

The mailbox slot is like the public key: anyone can use it to send a message securely. The key that opens the mailbox is the private key: only the owner has it. Even if someone watches you drop a letter into the mailbox, they cannot read it because they do not have the key.

Asymmetric encryption works the same way. If someone were to intercept your emails, the contents would appear as gibberish because that person does not have access to the private key used to protect the communication channel.

S3 buckets allow you to access your data using either HTTP (unencrypted) or HTTPS (encrypyed) endpoints. It is highly recommended to only allow access via the latter. To enforce this, you can apply the following bucket policy:

{
    "Version":"2012-10-17",              
    "Statement": [{
        "Sid": "RestrictToTLSRequestsOnly",
        "Action": "s3:*",
        "Effect": "Deny",
        "Resource": [
            "arn:aws:s3:::<yourBucket>",
            "arn:aws:s3:::<yourBucket>/*"
        ],
        "Condition": {
            "Bool": {
                "aws:SecureTransport": "false"
            }
        },
        "Principal": "*"
    }]
}

Public/Private buckets

In AWS you have two types of buckets, public and private. As you may have already guessed by their names, public buckets can be accessed by anyone in the world whereas private ones are only accessible to authorized individuals.

Luckily for all, new buckets are private by default so you would need to go on the extra mile to make it public.

But hey, mistakes can happen.

To ensure you have a layered defense that prevents someone from simply turning a private bucket into a public one, consider enabling the Block Public Access feature.

Now, this feature can be enabled at three levels: bucket, account, and organization:

Block Public Access (Bucket) -> This is the level you are most likely to have enabled by default when a bucket is private.
Block Public Access (Account) -> This level blocks public access to all buckets across an account.
Block Public Access (Organization) -> If you work at a company that have a large AWS organization, you can turn this feature on at the org level so no buckets within your org can be made public.

Least privilege

You may have already come across the principle of least privilege, but if not, let me introduce it. Least privilege is a security concept that states you should grant an entity (such as a person, application, or service account) only the minimum set of permissions required to perform a specific task, and no more.

Applying this principle helps reduce the risk of accidental misuse or malicious activity. Therefore, to ensure your data is protected in S3, you must carefully scope IAM permissions so that users and services can access only the buckets and actions they truly need.

For example, if you have a bucket that stores marketing information, only the Marketing team should have access to it.

Keep in mind that least privilege is not a one-off exercise. It requires ongoing maintenance and regular audits as responsibilities change, teams are reorganized, or access requirements evolve over time.

Versioning & MFA delete

If you want to further protect your data against malicious or accidental deleition, you can enable versioning and MFA delete on buckets.

When versioning is enabled on a bucket, S3 keeps multiple versions of an object instead of permanently replacing or removing it. This allows you to recover previous versions of a file if it is deleted or modified by mistake. FYI, this feature cannot be disabled once it's enabled on a bucket and it comes with extra cost due to the multiple versions stored!

To go one extra step further, you can enable MFA Delete. MFA Delete requires users to provide multi-factor authentication (MFA) in addition to their credentials when performing sensitive operations such as permanently deleting an object version or suspending versioning on a bucket. This adds an extra layer of security by ensuring that even if credentials are compromised, critical destructive actions cannot be performed without physical access to the MFA device.

Together, versioning and MFA Delete provide an effective safeguard against data loss, whether caused by human error or malicious activity.

Top 10 AWS Security Mistakes Beginners Must Avoid

Nicolás — Sun, 04 Jan 2026 10:24:41 +0000

AWS provides a highly secure cloud platform, but that does not mean your environment is secure by default. As we explored in the AWS Responsibility Model article, security is a shared responsibility so you must do your part to ensure your resources are safe.

Most AWS security incidents do not involve advanced attackers or zero-day exploits. They happen because of basic mistakes, often made by people who are new to the cloud and still applying on-prem thinking to a very different environment.

This article walks through the top 10 AWS security mistakes beginners make, explains why they are risky, and shows how to avoid them.

1. Using the Root Account for Daily Work

Every AWS account has a root user with unlimited privileges. This is effectively "God Mode" and can do almost anything on your account. Beginners often use it because it’s easy.

Why It’s a Problem

Root user has full control over the account
If compromised, your entire account is at risk

How to Avoid It

Ensure the root user uses a strong password
Don't create access keys for the root user
Enable MFA on the root user
Create alternative access (IAM user or IAM role) for daily use

Note
It's recommended not using the root account unless absolutely necessary.

If you are experimenting with AWS, an IAM user will likely suffice for the time being. However, keep in mind that IAM users have long-term credentials such as passwords and access keys, which you should rotate regularly.

The best practice, however, is to create an use an IAM role for daily operations as roles provide temporary credentials by default.

2. Not Enabling Multi-Factor Authentication (MFA)

Passwords alone are not enough, especially in the cloud that can be accessed from anywhere in the world.

Why It’s a Problem

If credentials are leaked through phishing or reuse, attackers can log in immediately.

How to Avoid It

Adding MFA adds a second layer of defense that protects your account. Attackers would need to also get hold of the second authenticator factor to successfully log in.

Recommendations:

Enable MFA for the root account
Require MFA for privileged IAM users

3. Having public S3 buckets

S3 is one of the core services in AWS. It easily lets you store objects like files, images, videos, etc.

Why It’s a Problem

Public S3 buckets can expose:

Customer data
Backups
Logs
Intellectual property
Source code

Many major data breaches started this way. If data should not be public, explicitly prevent it.

How to Avoid It

All new buckets are private by default, but a single misconfiguration can unintentionally expose their contents to the internet.

Recommendations:

Review bucket policies carefully
Implement alerts to notify you when a bucket goes public (AWS Config, CloudTrail, EventBridge services can help)
Enable S3 Block Public Access at the account level or organization-level

Note
Having public S3 buckets is not inherently a security issue. There are valid use cases for public buckets. Just ensure the objects stored in them are truly intended to be public.

4. Overly permissive Security Groups

Security Groups are AWS’s primary network firewall, but beginners often configure them too loosely, or use the default ones because they "just work" at the cost of being highly permissive.

Why It’s a Problem

Overly permissive security groups are problematic because they significantly increase the attack surface of your environment.

When services like SSH, RDP, or databases are exposed to the internet, they become easy targets for automated scans, brute-force attacks, and exploitation attempts.

Even if the underlying application is secure, unnecessary exposure increases the likelihood of compromise.

For instance, a security group with a rule like:

SSH (22) from 0.0.0.0/0

allows SSH traffic from the entire internet.

How to Avoid It

Review inbound and outbound rules regularly
Restrict access to known IP ranges and expected ports/traffic
Use AWS System Manager Session Manager instead of SSH where possible
Monitor changes via AWS Config or a custom solution (i.e. EventBridge + Lambda)

5. Insufficient Password Policies

Weak or poorly enforced password policies are a common security gap in AWS environments, especially in accounts that were set up quickly or without security in mind.

By default, AWS allows basic password requirements unless you explicitly configure stronger rules, and many beginners never revisit these settings.

Why It's a Problem

Passwords are often the first, and sometimes only, line of defense protecting AWS accounts.

If password policies are too lenient, they become easy targets for brute-force attacks, credential stuffing, or simple guessing.

This risk is amplified when users reuse passwords across multiple services or fall for phishing attempts.

An attacker who successfully compromises a single IAM user with a weak password may gain access to sensitive resources, escalate privileges, or move laterally within the account.

How to Avoid It

Enforce strong IAM password policies (length, complexity, rotation)
Require multi-factor authentication (MFA) for all users, especially privileged ones
Disable unused IAM users and credentials

Strong password policies are a basic control, but they remain one of the most effective ways to reduce account compromise, especially when combined with MFA.

Note

Prefer IAM roles over long-lived user passwords whenever possible.

6. Insecure Use of Access Keys

AWS access keys provide programmatic access to your account and services. While they are powerful, they are also easy to misuse.

Why It's a Problem

Access keys are long-lived credentials. If they are exposed through source code repositories, configuration files, logs, or shared scripts, an attacker can use them immediately, often without triggering obvious alarms.

Unlike passwords, access keys do not expire by default and are frequently forgotten after being created.

Once compromised, access keys can be used from anywhere in the world to interact with AWS APIs, potentially allowing attackers to read data, launch resources, or incur significant costs.

How to Avoid It

Use IAM roles instead of access keys whenever possible
Store secrets in AWS Secrets Manager or Parameter Store (Secure String)
Rotate access keys regularly and delete unused ones
Monitor access key usage with CloudTrail

Access keys should be treated like highly sensitive secrets. In most modern AWS environments, they should be the exception, not the default.

7. Overly Permissive IAM Policies

Beginners often use policies like AdministratorAccess or *:* just to make things work.

Why It’s a Problem

Violates the principle of least privilege
Increases blast radius if credentials are compromised
Makes auditing difficult

How to Avoid It

Start with minimal permissions
Grant only what is required
Use AWS-managed policies as learning references, not defaults

Convenience today becomes risk tomorrow.

8. Logging and Monitoring Gaps

If you don’t log activity, you won’t know when something goes wrong.

Why It’s a Problem

Without logs, you cannot:

Detect suspicious behavior
Investigate incidents
Prove compliance

How to Avoid It

Enable AWS CloudTrail
In large organizations with multiple AWS accounts, configure an organization trail in CloudTrail
Protect CloudTrail so that only the security team can change settings
Send logs to a protected S3 bucket
Monitor alerts using CloudWatch, Security Hub or a third-party solution

Visibility is a core security requirement, not an optional feature.

9. Insecure use and storage of Secrets and Access Keys

Hard-coding passwords and API keys is a common beginner shortcut. Similarly, secrets that never change are secrets that eventually get compromised.

One of the most common security oversights in AWS environments is creating credentials: passwords, access keys, or secrets, and then leaving them unchanged for months or even years.

Why It’s a Problem

Credentials can leak via source control
They are hard to rotate
They are often shared unintentionally

How to Avoid It

Use AWS Secrets Manager or Parameter Store for secrets
Use IAM roles instead of access keys and IAM users
Rotate credentials frequently.

10. No encryption of stored data

Failing to encrypt data at rest is a common security gap in AWS environments, particularly in early-stage or test accounts where security controls are often overlooked.

While AWS supports encryption for most storage services, it is not always enabled automatically or consistently across all resources.

Why It's a Problem

Unencrypted data is vulnerable if storage is accessed by unauthorized users, compromised credentials, or misconfigured permissions.

Without encryption, anyone who gains access to the underlying data can read it directly, including sensitive customer information, credentials, backups, or intellectual property.

Encryption adds a critical layer of protection by ensuring that even if data is accessed improperly, it cannot be read without the appropriate encryption keys.

How to Avoid It

For S3 buckets, encryption at rest is enabled by default but consider using your own encryption key
Enforce encryption in transit when interacting with S3 buckets
Require encryption for EBS volumes and snapshots
Use AWS Key Management Service (KMS) to manage encryption keys
Enforce encryption using AWS Config rules or service control policies (SCPs)

Security Groups vs Network ACLs: The Two Firewalls You Didn’t Know You Were Using in AWS

Nicolás — Sat, 03 Jan 2026 11:55:33 +0000

Firewalls are essential for deciding what traffic is allowed in or out of a network. In traditional, on-prem networks, controlling traffic is usually straighforward, not because the configuration is simple, but because the structure is (hopefully) well undestood.

You know how the network is laid out, what connects to what, and what should be talking with what. In other words, you (hopefully) know the internal details.

Security teams are used to thinking in terms of:

A single firewall (or a small number of them)
Clearly defined network edges
Rules applied at obvious choke points

When moving to the cloud, this mental model no longer fully applies, although the concept of firewall still exist, it appears under a different name.

Firewalls in AWS

AWS does not have a single perimeter firewall protecting your environment. Instead, traffic control is distributed across multiple layers and services. Security decisions are no longer made in just one place, but at different points within the network, sometimes at the subnet level, sometimes at the resource level.

This shift in approach is often one of the biggest challenges for people new to AWS. The tools are different, the terminology is new, and familiar concepts do not always behave the same way.

Networking basics

Before discussing how we can control traffic in AWS, it is important to understand a few core networking constructs that everything else builds upon.

VPC (Virtual Private Cloud)

A VPC is a logically isolated network within AWS. You can think of it as your own private data center network in the cloud.

Within a VPC, you define:

The IP address range (CIDR block)
Subnets
Routing rules
Network security controls

By default, resources inside a VPC cannot be accessed from the internet unless you explicitly allow it.

This gives you full control over how traffic flows into, out of, and within your environment.

Subnet

A subnet is a subdivision of a VPC’s IP address range. Each subnet exists within a single AWS Availability Zone and represents a smaller network segment.

Subnets are commonly used to separate workloads based on purpose or exposure, for example:

Public subnets (internet-facing resources)
Private subnets (internal services, databases)

Controlling network traffic

Two of the most important network security controls in AWS are Security Groups and Network ACLs. Both act like firewalls, but they operate at different layers and follow different rules.

Security Groups: protect individual resources (like EC2 instances)
Network ACLs: protect entire subnets

Let's look at the following figure to understand it better:

Traffic flows from the internet into AWS, but before it can reach your application, it must first stop at the subnet level, where a Network ACL verifies whether the traffic is allowed. If it is, the traffic continues and stops at the doorway of your application. There, a gatekeeper performs a second verification check to ensure the traffic is allowed to reach the application.

As you can see, both controls work in combination to protect your workloads, as traffic can be dropped at either layer if the checks are unsuccessful.

Let’s examine them in more detail.

Network ACL

A Network ACL (NACL) acts like a security gate at the entrance of a building. It controls:

What traffic can enter a subnet
What traffic can leave a subnet

NACLs are applied at the subnet level and are free of charge. Every subnet must be associated with a NACL. If none is specified, the subnet is associated with the default NACL, which allows all inbound and outbound traffic. A subnet can only be associated with one NACL.

NACLs are composed of rules that control traffic. Each rule can either allow or deny traffic, and rules are evaluated in order based on a number you assign to each rule. Evaluation starts with the lowest number and continues until the traffic matches a rule.

A key concept of NACLs is that they are stateless, meaning inbound and outbound connections are treated separately. This means that both inbound and outbound rules must explicitly allow traffic for a connection to be successful.

You must think about both directions:

Inbound traffic must be explicitly allowed
Outbound traffic must also be explicitly allowed

Let's look at an example.

Imagine that you have a subnet where you host a public web server meant to be accessed from anywhere in the world by anyone.

You need both HTTP (unencrypted, not recommended) and HTTPS traffic to reach your application.

In this situation, your Inbound rules might look like this:

100 ALLOW HTTP (80) 0.0.0.0/0
110 ALLOW HTTPS (443) 0.0.0.0/0
DENY ALL

Because NACLs, are stateless, we need to have rules allowing the outbound connectivity:

100 ALLOW ALL 0.0.0.0/0
DENY ALL

Security Groups

A security group is associated with a resource and controls the traffic that reaches it and leaves it. In other words, it controls inbound and outbound traffic to and from the resource.

Similar to NACLs, security groups are composed of rules that control both inbound and outbound traffic. The components of these rules are:

the source (i.e. IP address, IP range)
port range (i.e. 22, 80, 25-30)
protocol (TCP, UDP, ICMP)

Unlike NACLs, which support both ALLOW and DENY rules, security groups only support ALLOW rules. Another difference is that you can attach multiple security groups to a single resource.

However, the most important difference between NACLs and security groups is that security groups are stateful. This means they keep track of allowed connections. If inbound traffic is allowed, the corresponding return traffic is automatically allowed.

You only need to think about the initial request.

You do not need to explicitly allow response traffic.

Continuing with the web server example, the traffic has passed the NACL and is now attempting to reach your application.

You create a security group with the following rules:

Allow inbound HTTP (port 80) from anywhere (0.0.0.0/0)
Allow inbound HTTPS (port 443) from anywhere (0.0.0.0/0)

If a user sends a request on port 80 or 443, the Security Group allows it, and the response is automatically allowed back.

You do not need to add a rule for return traffic.

This is what “stateful” means.

Comparison

When to use them

Both Network ACLs and Security Groups act as firewalls, and are typically used together rather than as alternatives. You can think of them as different security layers protecting your resources.

Ideally, you should configure both of them appropriately to ensure that only expected traffic reaches your application.

When to Use Security Groups

Security Groups should be your primary mechanism for controlling traffic in AWS and you want:

Fine-grained control at the resource level (EC2, ALB, RDS, etc.)
Simple, intuitive rules that follow the application logic
Automatic handling of return traffic (stateful behavior)
Micro-segmentation between tiers (web, application, database)

In practice, most application level access decisions, such as which services can talk to each other, are enforced using Security Groups.

When to Use Network ACLs

Use Network ACLs when you need:

A broad security boundary at the subnet level
An additional layer of protection to block or restrict traffic
Explicit deny rules (which Security Groups do not support)
Guardrails that apply to all resources within a subnet

NACLs are often used as a secondary control to enforce high-level policies, such as blocking known malicious IP ranges or preventing unintended exposure.

AWS Shared Responsibility Model Explained

Nicolás — Tue, 30 Dec 2025 10:42:08 +0000

One of the most dangerous assumptions when starting to work with cloud environments is believing that workloads are secure by default. After all, if you are using the cloud, the provider should take care of security, right?

Not exactly.

Cloud providers are responsible for security, but only to a certain extent.

Imagine checking into a hotel and booking a room. The hotel is responsible for maintaining the building, hiring security staff, and monitoring cameras to secure entrances and hallways. It provides locks on the doors, installs smoke detectors and sprinklers, ensures that electricity and water work, and even offers a safe in each room for guests’ valuables.

In other words, the hotel is responsible for keeping the hotel itself secure.

You, the guest, are still responsible for locking your room when you leave. You decide who is allowed to enter, and you choose whether or not to use the safe to protect your valuables.

The hotel gives you a lock, but you must actually use it.

The same concept applies in the cloud. Cloud providers ensure that the underlying cloud infrastructure is secure, but you are responsible for securing your workloads and protecting your environment.

This division of responsibility, in the context of AWS, is known as the Shared Responsibility Model, and it is exactly what we are going to explore in this post.

What is the AWS Shared Responsibility Model?

The AWS Shared Responsibility Model defines how security responsibilities are divided between:

AWS (the cloud provider) is responsible for security of the cloud
You (the customer) are responsible for security in the cloud

This concept is best illustrated by [AWS] itself:(https://aws.amazon.com/es/compliance/shared-responsibility-model/)

AWS Responsibility

AWS is responsible for protecting the infrastructure that runs all AWS services. This includes:

Physical data centers (buildings, locks, guards, cameras)
Hardware (servers, storage devices, networking equipment)
Global infrastructure (regions and availability zones)
Core services infrastructure (compute, storage, networking foundations)
Hypervisors and underlying virtualization layers

For example, if a physical server in an AWS data center fails or is physically tampered with, AWS is responsible for detecting and resolving that issue. Customers never manage or even see this hardware, and as such, they don't need to worry about:

Data center access control
Physical server patching
Power, cooling, or hardware lifecycle

AWS handles all of it.

Customer responsiblity

As a customer, you are responsible for how you configure and use AWS services, which includes:

IAM users, roles, and permissions
Operating systems (for EC2)
Network configurations (VPCs, security groups, NACLs)
Data encryption and key management
Application security
Logging and monitoring
Compliance with your own regulatory requirements

Let's look at an example to better understand this.

Imagine your marketing team stores images of an unreleased product in a private S3 bucket. The images are protected from the outside world because the bucket has strict access controls. However, a mistake occurs and the S3 bucket is made public temporarily, but long enough for someone to access and download the images.

Even though the bucket is hosted on AWS infrastructure, this incident is your responsibility, because you control and manage the security configuration of that bucket.

Real Examples

Amazon EC2 (Virtual Servers)

With EC2, you have significant control and responsibility.

AWS handles:

Physical servers
Hypervisor
Data center security

You handle:

OS patching (Linux/Windows updates)
Firewall rules (security groups)
SSH/RDP access
Installed software vulnerabilities
Application-level security

Common mistake:
Assuming AWS patches your EC2 operating system automatically. AWS does not.

Amazon S3 (Object Storage)

S3 is fully managed, but configuration is your responsibility.

AWS handles:

Storage infrastructure
Durability and availability
Physical protection of disks

You handle:

Bucket access policies
Public vs private access
Encryption settings
Who can read or write data

Common mistake:
Leaving buckets publicly accessible because “AWS would block that if it was unsafe.”

AWS Lambda (Serverless)

As services become more managed, your responsibilities decrease, but never disappear.

AWS handles:

Servers and OS
Runtime environment
Scaling and availability

You handle:

IAM permissions for the function
Secure handling of secrets
Application logic
Data access controls

Why This Model Matters for Security

There is a common misconception that security incidents in AWS are caused primarily by sophisticated attacks, but that could not be farther from the truth.

In reality, most incidents in AWS stem from customer-side errors, such as misconfigurations, weak identity controls, and insufficient monitoring. This is consistently highlighted in industry research, including Tenable 2025 Cloud Security Risk Report and Top Threats to Cloud Computing 2024 report published by the Cloud Security Alliance (CSA)

Because of this, it is critical to understand what falls under your responsibility so you can apply the appropriate security controls and guardrails to prevent issues such as:

Public data exposure
Overly permissive IAM roles
Data tampering
Unpatched systems
Missing logs and alerts

Final Thoughts

AWS provides a highly secure cloud platform, but security is a shared effort. AWS secures the foundation; you secure everything built on top of it.

WhatsApp Ghost Pairing: A Silent Abuse of Linked Devices

Nicolás — Tue, 23 Dec 2025 16:00:00 +0000

In the previous blog, we discussed how to detect if your WhatsApp account has been compromised and the safeguards you can adopt to protect your account against common cyber threats.

Today, I’m going to show you a specific attack that aims to monitor and spy on your conversations without your awareness. This technique is called Ghost Pairing.

What is Ghost Pairing?

Ghost Pairing is an attack vector in which an attacker secretly links their own device to your WhatsApp account using the official Linked Devices feature. Their intention is not to fully take over your account but to let you continue using it normally while they:

Read all messages you send and receive
Access your photos, videos, and documents
Impersonate you by sending messages to your contacts

Sounds scary, right?

How Ghost Pairing Works

WhatsApp allows one account to be linked to up to four devices. Ghost pairing abuses this design. The attack does not target WhatsApp’s encryption or internal security. Instead, it targets the user, exploiting human behavior to grant unauthorized access.

There are two common scenarios in which this attack can occur:

Physical Access

If you leave your phone unlocked and unattended, an attacker can take advantage of that moment to link your WhatsApp account to their own device.

No verification SMS is sent

You are not logged out of your account

The attacker can dismiss the push notification WhatsApp sends for new linked devices

Remote access

In this scenario, the attacker gains access without physically handling your phone. This usually involves social engineering techniques designed to trick you into revealing information:

The attacker convinces you to share the WhatsApp verification code you received via SMS. (Reminder: never share this code with anyone.)
The attacker impersonates one of your contacts and attempts to trick you into providing the verification code or visiting a malicious link
You visit a seemingly innocent website that claims you must verify your phone to view content, but in the background it collects your verification code

Why It’s Dangerous

Ghost pairing is especially risky because:

No obvious takeover – your account still works
Real-time spying – messages sync instantly
Persistent access – stays active until manually removed
Perfect for scams – attackers can impersonate you
No advanced skills needed - attackers simply exploits an official WhatsApp feature

Common Signs of Ghost Pairing

Be alert for these warning signs:

A linked device you don’t recognize under Settings → Linked Devices
Messages marked as “read” when you didn’t open them
Contacts receiving messages you don’t remember sending
Unusual activity times in Last Seen

How to Protect Yourself

The good news is ghost pairing is easy to prevent if you follow basic security practices:

Lock your phone (PIN, biometrics, auto-lock) and don't leave it unattanded
Regularly check Linked Devices and remove any unfamiliar ones
Enable notifications for new linked devices
Enable two-step verification (2FA) for your WhatsApp account

If you found this article helpful, share it with your friends and family to help them stay informed and protected. Remember: security is everyone’s responsibility.

How to Tell If Your WhatsApp Account Is Hacked — and How to Protect Yourself

Nicolás — Mon, 22 Dec 2025 13:50:08 +0000

WhatsApp is the most widely used instant messaging platform on the planet, with over 3.5 billion active accounts in 2025. For many people, it has become the de facto channel for personal communication, and small businesses and even larger corporations have also adopted it as an easy way to communicate with customers.

WhatsApp’s global reach and its importance in people’s daily lives make it a high-value target for cybercriminals. For this reason, it’s essential to understand how to protect yourself and recognize the warning signs that your account may be at risk.

Recognizing the Signs Your WhatsApp Account May Be Compromised

Unexpected Activity

Messages are marked as read without your involvement.
Messages or media you didn’t send appear in your chats.
New contacts or group chats appear that you don’t recognize or didn’t add.
Your Last Seen status shows activity at times when you weren’t using the app.

Unknown Linked Devices

Linked Devices is a feature that allows you to securely access your WhatsApp account from multiple devices (such as WhatsApp Web, desktop apps, or another phone). These linked devices have full access to your chats and media, meaning they can read your messages, view your photos, and send messages to your contacts.

For this reason, it’s important to periodically review your list of linked devices and immediately remove any that you don’t recognize.

Changes to Profile Information

If your profile photo, status, or display name changes without your consent, it’s a strong indication that someone else may have access to your account.

You Receive Unexpected Verification Codes

If you receive an SMS containing a WhatsApp verification code that you did not request, it likely means someone is attempting to register your phone number on another device.

DO NOT SHARE THIS CODE WITH ANYONE. Sharing it would give them full access to your account.

You Can’t Log In or Have Been Logged Out

If WhatsApp reports that your number is “no longer registered” on your device, or if you are suddenly logged out and unable to sign back in using your phone number, your account may have been compromised.

What to Do If You Suspect Your Account Is Comrpomised

Once you identify suspicious activity, take the following steps immediately.

Step 1: Regain Control

Open WhatsApp and sign in using your phone number.

Enter the six-digit verification code sent via SMS. This will automatically log out any existing sessions on devices controlled by an attacker.

If you’re unable to receive the six-digit code because the attacker has enabled or changed two-step verification, WhatsApp typically enforces a waiting period (for example, seven days) before you can register the number again without the two-step verification PIN.

Step 2: Log Out Unknown Devices

If you still have access to your account, go to Settings → Linked Devices.

Review the list and log out of any devices you don’t recognize.

Step 3: Alert Your Contacts

Notify friends, family, and colleagues that your account may have been compromised so they do not fall for scams sent from your profile.

Practical Tips to Protect Your WhatsApp Account

Enable Two-Step Verification (2FA)

Even though two-step verification is an optional security feature, it's highly recommended enabling it as it significantly strengthens your account by adding a six-digit PIN required to register your number on a new device.

It is the single most effective defensive measure you can enable.

To enable it, go to:

Settings → Account → Two-step verification → Enable.

Then:

Enter a six-digit PIN
Add an email address to help you recover your PIN if you forget it

Never Share Your Verification Codes

WhatsApp will never ask you for your SMS verification code or your two-step verification PIN. Sharing either of these, even with someone claiming to be WhatsApp support, almost always results in account takeover.

Monitor Linked Devices Regularly

Periodically review the list of devices linked to your WhatsApp account and log out of any sessions you don’t recognize.

Go to Settings → Linked Devices to see the full list.

Use Strong Device Security

Protect your phone with a secure PIN, biometric lock, or strong password. This reduces the risk of someone accessing your WhatsApp account if your device is lost or stolen.

Also, make sure your phone is locked when you leave it unattended. Anyone with access to an unlocked phone could link their own device to your WhatsApp account and monitor your conversations.

Be Wary of Links, Files, and Phishing Attempts

Attackers often send malicious links or files designed to install malware or trick you into revealing sensitive information. Avoid clicking unknown links, opening suspicious attachments, or installing apps from unofficial sources.

Update WhatsApp and Your Operating System

Security updates frequently patch vulnerabilities that attackers exploit. Enable automatic updates for WhatsApp and your device’s operating system.

Enable Push Notifications on your phone

WhatsApp sends a notification whenever a new device is linked to your account. Keeping notifications enabled allows you to quickly detect and remove unauthorized devices.

Avoid Unofficial Apps and Tools

Linked Devices is a feature officially provided by WhatsApp at no cost. Using unofficial or third-party apps to link your account can expose your messages and credentials, putting your account at serious risk.

Final Thoughts

WhatsApp is widely regarded as a secure platform thanks to its end-to-end encryption. However, account takeovers remain common because attackers typically exploit human behavior through social engineering rather than breaking cryptographic protections.

By recognizing the warning signs of compromise and adopting strong account security practices, especially enabling two-step verification and carefully handling verification codes and links, you can significantly reduce your risk and better protect your communications.

When a seemingly innoffensive conversation with AI turns malicious

Nicolás — Tue, 16 Dec 2025 21:15:47 +0000

AI has changed the way we interact with technology in many ways, from simple tasks such as generating text and helping with homework to more technical ones like creating web pages and assisting developers with code reviews.

One of the most significant changes has been the way we search for information. It is now common to default to an LLM such as ChatGPT, Gemini, Grok, or Claude to ask about almost anything we can think of: planning trips, searching for historical facts, explaining complex documentation, or helping us fix problems by providing step-by-step guides.

It is in this last area where cybercriminals have found a way to exploit the trust users place in these platforms, creating an attack vector that tricks users into downloading and installing malware designed to steal credentials, as reported earlier this month by the cybersecurity company Huntress.

What category does this attack fit into?

Social engineering through the “impersonation” of a legitimate LLM conversation.

How does it work?

I will leave out the technical details for the sake of simplicity and refer you to the original article. In a nutshell, the attack abuses the shareable conversation feature available in
Grok and OpenAI.

This feature allows users to generate a unique URL that can be easily shared on social media, instant messaging platforms, or public forums, and anyone with the link can access the conversation.

These conversations can be indexed by search engines and may rank highly in search results, causing them to appear at the top of the page and point to a seemingly legitimate conversation.

Why does it work?

The conversations resemble step-by-step guides on how to perform common operations on macOS devices, such as clearing storage.

Users access the link through a browser and see a real conversation with an LLM—real in the sense that it is the actual UI and platform used when interacting with Grok or ChatGPT.

This creates an element of trust, as users are familiar with these platforms. However, without realizing it, the steps include malicious terminal commands that open the user’s computer to attackers.

How to protect yourself

AI is not flawless. We all know that LLMs can hallucinate and provide made-up information in an attempt to be helpful. In that sense, this scenario is not entirely different. If an LLM were to ask for your Social Security number, your bank password, or guide you through making a bank transfer to an account number you don't know, you would not do it, right?

Here, instead of asking for sensitive information directly, the model instructs users to run commands in their device’s terminal without clearly explaining what those commands do - and those commands can be highly destructive.

The recommended precautions

Never provide sensitive information.
Never execute terminal commands unless you fully understand what they do, even if they appear to come from a trusted source.
Follow good password hygiene to keep your accounts secure, such as never reusing passwords and using a password manager to generate strong, unique credentials.

Beware the Forgotten Tab: Understanding and Preventing Tabsnabbing

Nicolás — Sun, 09 Nov 2025 09:18:56 +0000

If you’re anything like me, your curiosity tends to get the better of you. You start reading a blog post, click on a related article (or two… or ten), and before you know it, your browser looks like a chaotic battlefield of open tabs.

This kind of tab-hopping often comes from our multitasking instincts — reading a bit here, jumping there, chasing the next interesting thing that catches our eye. Before long, you’ve gone so far down the rabbit hole that you’re learning how nut prices in Asia affect global trade, even though all you wanted to know in the first place was whether it’s going to be sunny tomorrow.

Now, having too many tabs open isn’t really a problem — at least, not if your computer can handle it. But what if I told you that, somewhere in that ocean of forgotten tabs, something darker might be waiting? Something that could turn against you the moment you let your guard down?

Welcome, my friend, to Tabsnabbing — a sneaky phishing technique that exploits your trust in your own open tabs.

What Is Tabsnabbing?

Tabsnabbing is a type of phishing attack that leverages inactive browser tabs. When a user navigates away from a page but leaves its tab open, a malicious site can detect that state and replace its content with a realistic-looking login page (for example Gmail, GitHub, or an online bank). If the user returns and enters their credentials, the attacker captures them.

Tabsnabbing Types

There exist two types of tabsnabbing:

Passive (the most common)
This is the one that changes the original content of the website, when the tab is inactive, for a login page. When you return to it, it gives the impression that the session expired, so the user is more likely to enter their credentials.
Reverse
This one occurs when you click on a link that opens a new browser tab. Unknowingly, this action triggers a process that automatically change the content of previous page.

Why It Works So Well

Tabsnabbing preys on two simple things:

Trust
You think the tab is still the site you opened earlier (e.g., “That’s my Gmail tab, right?”).
Distraction
We multitask. We leave tabs open for hours. Sometimes days.

The combination means that when you return to a tab and see a login page, your brain fills in the blanks: “I must’ve been logged out.” And that’s when the attacker wins.

What Risks We Face

Identity Theft
Attackers can pretend they are you if they manage to your credentials for email account, your social accounts (TikTok, Instagram, Facebook...)
Financial Loss
Capturing your bank credentials can lead to attackers transfering money out your account, using your card details to purchase goods
Access to sensitive information
Company's proprietary data if your work credentials are captured, your medical records...

How to Protect Yourself

Close tabs you are not using
Verify the URL before entering credentials. If in doubt, close the tab and navigate to the login page.
Don't reuse passwords
Enable MFA whenever possible

Final Thoughts

Tabsnabbing is one of those web security gotchas that’s easy to underestimate. It doesn’t rely on zero-days or fancy exploits — just our everyday browsing habits.

It’s a good reminder that security is as much about psychology as it is about code.

Understanding Hashing: The Backbone of Data Integrity in Cybersecurity

Nicolás — Fri, 31 Oct 2025 11:22:28 +0000

If you’re just starting out in cybersecurity, you’ve probably already come across the term hash or hashing, a fundamental concept closely tied to Integrity, one of the three pillars of the CIA Triad: Confidentiality, Integrity, and Availability.

What Is Integrity?

Integrity means ensuring data hasn’t been tampered with. Basically, that it remains complete, accurate, and trustworthy.

This is crucial. Imagine a bank with thousands of customers. The integrity of every transaction and account balance must be preserved. If someone altered even a few records, customers might log in to find incorrect balances.

Integrity also protects organizations from software supply chain attacks. Suppose a company, OptimusLab, downloads software from what it believes is a trusted vendor. Unknown to them, a malicious actor has tampered with the vendor’s website, replacing the legitimate installer with a compromised one containing malware.

If OptimusLab installs the file without verifying its integrity, their internal network could be infected — leading to data breaches, ransomware, and major reputational damage.

That's where hashing comes in!

Many software vendors publish the hash value (e.g., a SHA-256 checksum) of their official downloads. When you download the file, you can compute its hash locally and compare it to the one on the vendor’s site.

If the hash match, then the file is authentic, and if it doesn't match, well, the file is either corrupted or has been modified.

Alright, but what exactly is a hash?

A hash is a fixed-length string of characters produced by a mathematical algorithm that uniquely represents the original data. Any small change to the original input, will produce a completely different hash.

It's important to undestand that hashes are one-way operation. We can obtain the hash from an input, but we cannot obtain the original input from a hash.

The most common mathematical algorithms, also known as hash functions, are:

MD5: Fast but insecure due to collisions — not recommended.
SHA-1: Once standard, now vulnerable to collision attacks.
SHA-256 / SHA-3: Modern, secure, and widely used in encryption, blockchain, and password hashing.
Argon2id: Recommended for passwords

For a hash function to be considered good, it must be:

Deterministic: The same input always produces the same hash.
Fixed Output Length: Hash size doesn’t depend on input size.
Pre-image Resistance: It’s infeasible to reverse-engineer the input from the hash.
Collision Resistance: It’s hard to find two inputs with the same hash.
Avalanche Effect: Small input changes cause big differences in output.

Hashing in action

Let's run a simple python script using the built-in hashlib module to see how hash values actually look like.

If we run the following code using "Hello World" as input...

import hashlib

text = "Hello World"
hash_sha256 = hashlib.sha256(text.encode()).hexdigest()
hash_md5 = hashlib.md5(text.encode()).hexdigest()
hash_sha128 = hashlib.sha128(text.encode()).hexdigest()
print(f"Sha256: {hash_256} )
print()
print(

... we would get:

Sha256: a591a6d40bf420404a011733cfb7b190d62c65bf0bcda32b57b277d9ad9f146e
Sha128: 0a4d55a8d778e5022fab701977c5d840bbc486d0
MD5: b10a8db164e0754105b7a99be72e3fe5

Now look what happens with a tiny change. We will now use "hello world"

Sha256: b94d27b9934d3e08a52e52d7da7dabfac484efe37a5380ee9088f7ace2efcde9
Sha128: 2aae6c35c94fcfb415dbe95f408b9ce91ee846ed
MD5: 5eb63bbbe01eeed093cb22bb8f5acdc3

That’s the avalanche effect in action.

Hypothetical Scenario

Let's now analyze a made-up scenario to better understand the critical role of hashing in cybersecurity.

Background

FinSecure Bank, a mid-sized financial institution, relies heavily on its internal systems to track all employee logins, customer transactions, and administrative actions. These log files are essential for detecting fraud, investigating incidents, and maintaining compliance with regulatory frameworks such as PCI-DSS and ISO 27001.

The Incident

In early 2024, FinSecure noticed unusual behavior in one of its internal financial systems — a few high-value wire transfers had been approved outside of normal business hours. When the cybersecurity team began investigating, they encountered a major problem: the system logs had been tampered with.

Certain log entries showing administrative access at 2:14 AM were missing.
Others had been altered to appear as if the actions were performed by a different user.

Without trustworthy logs, the team couldn’t immediately determine who initiated the transactions, what commands were executed, or when the breach actually occurred.

Root Cause

The investigation revealed that the attacker had gained access to the logging server and manually edited log files to cover their tracks. Because FinSecure’s logs were stored as plain text and lacked cryptographic integrity protection, there was no easy way to detect the tampering until it was too late.

This made digital forensics extremely difficult, delaying the response and allowing the attacker to exfiltrate sensitive data before detection.

How Hashing Could Have Prevented This

If FinSecure had implemented hash-based integrity verification for their logs, this breach could have been identified immediately . Here’s how that would have worked:

Hashing Each Log Entry at the time it’s written. The hash value is then appended or stored separately in a secure location.
Chaining Hashes (Hash Chains)
To make tampering even harder, each log entry’s hash could incorporate the previous entry’s hash (a blockchain-like structure).This ensures that altering any single log invalidates the entire chain.
Verification and Alerts. A monitoring system can routinely verify hashes. If any hash mismatch occurs, it triggers an alert, signaling possible log tampering or file corruption.

Outcome With Proper Hashing

Had FinSecure used this approach:

Any modification to the logs would have broken the hash chain, immediately revealing unauthorized changes.
Investigators could have pinpointed exactly when tampering occurred and which records were affected.
Incident response would have been faster, and the attacker’s window of opportunity dramatically reduced.

Conclusion

In cybersecurity, integrity is trust — the assurance that what you see and rely on is authentic, complete, and untampered. Hashing lies at the heart of that trust. From verifying downloaded software and protecting passwords to securing digital signatures and preserving the integrity of system logs, hashes provide the mathematical foundation that keeps modern systems honest.

Without integrity, data becomes unreliable, investigations lose credibility, and even the most secure systems can be undermined from within. With it, organizations gain transparency, accountability, and confidence in every transaction and record they maintain.

As technology continues to evolve — and threats grow more sophisticated — understanding and implementing hashing correctly isn’t just a technical best practice; it’s a core security principle.

Part 1: Understanding AWS Identity and Access Management (IAM)

Nicolás — Sun, 26 Oct 2025 18:23:09 +0000

Identity and Access Management (IAM) is one of the most essential services in the AWS ecosystem. It handles authentication (who you are), authorization (what you’re allowed to do) across your AWS environment.

Every request to AWS is evaluated by IAM before it’s allowed or denied. In other words — IAM is the security gatekeeper for your AWS account.

The AWS Root User

Every AWS account starts with a single root user — the credentials created when you first set up your account. This is the most priviveled user in the account because it has unrestricted access to every resource.

As best security practice, avoid using the root user for daily operations.
Instead, create IAM users or roles with just the permissions they need.

Four Key IAM Concepts

As mentioned in one of my previous blogs, IAM is built around four fundamental building blocks:

IAM User

IAM Users are individual user user accounts, similar to those you’d find on any website that requires a username and password for authentication. They represent specific people or applications that need direct access to AWS.

IAM Role

IAM Roles represent a set of permissions associated with a specific function, for example, an Administrator or Security Engineer role. These roles define what actions an entity can perform. Roles are often used to delegate access without sharing long-term credentials.

IAM Group

IAM Groups are simply a collection of IAM Users. It allows you to manage permissions for multiple users at once instead of assigning policies individually.

IAM Policy

IAM Policies are documents written in JSON that explicitly define which actions are allowed or denied for a given user or role. A single policy can be attached to multiple users or roles.

Structure of an IAM Policy

Let's first see how an IAM policy looks like and break it down:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "CrossAccountRead",
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::shared-reports/*"
    }
  ]
}

"Version": "2012-10-17"

This specifies the policy language version — always use 2012-10-17 unless you have a very old AWS environment.

"Statement": [...]

Each item inside "Statement" is an individual permission rule.
A policy can have one or many statements.

Here, there’s only one statement (the one with "Sid": "CrossAccountRead").

"Sid": "CrossAccountRead"

Sid (Statement ID) is optional — it’s like a label or comment for readability.

"Effect": "Allow"

Specifies whether to allow or deny the action specified in the "Action" field, so the only two possible values are "Allow" and "Deny".

"Action": "s3:GetObject"
Defines what the Principal is allowed to do. In our case, the IAM user, group, or role this policy is attached to will allow them to download (read) objects from S3.
"Resource": "arn:aws:s3:::shared-reports/*"

Defines which AWS resource(s) the permission applies to.

This mean that the action "s3:GetObject" is scoped to only the shared-reports bucket.

🧠 How IAM Evaluates Access

Every request made to AWS (for example, listing S3 buckets or starting an EC2 instance) goes through IAM’s evaluation logic:

Default Deny – Everything is denied unless explicitly allowed.
Explicit Allow – If a policy allows the action, IAM grants it.
Explicit Deny – If a policy explicitly denies something, it overrides any allow.

Imagine we add the following DenyAllS3Actions statement to our policy:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "CrossAccountRead",
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::shared-reports/*"
    },
    {
      "Sid": "DenyAllS3Actions",
      "Effect": "Deny",
      "Action": "s3:*",
      "Resource": "*"
    }
  ]
}

Even though the policy explicity grants the s3:GetObject operation over the shared-reports bucket, it will be denied because there is an explicit deny in the DenyAllS3Actions statement that blocks every single S3 action.

There are some caveats to this as there are other controls that could be in place to further restrict permissions like Service Control Policies (SCPs). However, for simplicity's sake, we will assume that permissions are only controlled via default IAM policies and we will cover other controls in next blogs.

Resource-Based vs. Identity-Based Policies

Depending on which entity a policy is attached to, IAM policies are categorized as:

Identity-based policies: Attached to IAM users, groups, or roles.
Resource-based policies: Attached directly to AWS resources such as S3 buckets, SQS queues, or SNS topics.

They work similarly, but resource-based policies include a Principal field specifying who the policy applies to. These are also what enable cross-account access.

For example, suppose we have an S3 bucket we want to make public so everyone can access it:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowAllAccess",
      "Principal": "*",
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::shared-reports/*"
    }
  ]
}

We didn’t include the Principal element in our earlier examples because it wasn’t needed — in identity-based policies, the principal is implicitly the IAM user, group, or role the policy is attached to.

Managed, Inline, and Customer Policies

Other than the identity based and resource based policies, IAM policies are further categorized in:

AWS Managed Policies – Pre-built and maintained by AWS. Available to all customers.
Customer-Managed Policies – Custom policies you create and manage. They are reusable and often preferred over Inline policies.
Inline Policies – Policies embedded directly in a specific user, group, or role.

What’s Next

In Part 2, we’ll dive deeper into IAM policies — exploring:

Policy conditions and wildcards (*)
How AWS evaluates multiple overlapping policies

Cloud Security Myths

Nicolás — Tue, 21 Oct 2025 16:45:12 +0000

The cloud promised to simplify everything — agility, lower costs, and effortless global deployments in just minutes. But… what about security? Securing cloud environments has become far more complex than most expected, while opening a door for attackers is easier than ever.

By its very nature, the cloud allows both employees and cybercriminals to access systems from anywhere in the world — as long as they have the right credentials and no additional controls are in place to stop them. This accessibility, one of the model’s greatest strengths, is also its Achilles’ heel.

In this article, we’ll debunk some of the most dangerous myths about cloud security.

The Main Myths of Cloud Security

The cloud isn’t exactly new — it’s been around for nearly 20 years (if we count from the launch of AWS). Yet, several myths continue to shape how organizations approach cloud security today.

Myth 1: More tools = better protection

Many teams still believe that having more tools automatically means stronger security. The logic seems sound: more solutions should bring more visibility and control. However, in practice, accumulating tools without a proper integration strategy often has the opposite effect.

An environment overloaded with disconnected tools leads to fragmentation, inconsistent data, and blind spots that attackers can exploit. When each solution operates in isolation, information becomes scattered, and teams lose the big picture. The result? A disjointed and difficult-to-manage defense.

On top of that, an excess of irrelevant alerts causes alert fatigue, reducing analysts’ ability to respond effectively to real threats.

The key isn’t having more tools — it’s having the right ones, integrating them properly, and simplifying management. In cybersecurity, less can truly be more… if everything is well connected.

Myth 2: The cloud provider handles all the security

This one’s among the most dangerous.

Some people may think, “Now that we’ve migrated everything to the cloud, we don’t have to worry about security — the provider takes care of it.”

That’s only half true.

Yes, the provider ensures their infrastructure is secure, but you are responsible for protecting your data, identities, configurations, and access controls. In other words, they give you the tools — but they won’t stop you from exposing a database to the entire internet if you choose to.

This is known as the shared responsibility model, a principle used by all major cloud providers.

Myth 3: The cloud is less secure than on-premises environments

Because, of course, a data center in your garage must be safer, right?

Let’s be honest — the big cloud providers invest billions of dollars each year in cybersecurity, far beyond what most organizations or individuals could ever match.

As we mentioned earlier, the issue isn’t the cloud itself — it’s how it’s used. Understanding best practices and secure configurations is essential to avoid simple mistakes that could expose your organization.

Myth 4: Breaches are always caused by sophisticated hackers

It’s tempting to blame advanced threat actors or state-sponsored groups, but the truth is much simpler.

Most cloud incidents are caused by human error — open storage buckets, weak passwords, exposed APIs, excessive permissions, and so on.

In fact, according to Gartner, 80% of data breaches involve customer-side misconfigurations.

Final Thoughts

Cloud security isn’t about choosing the “most secure” provider — it’s about using the available tools wisely.

Your biggest enemy isn’t the cloud or even the sophisticated hacker; it’s complexity and human error.

That’s why it’s crucial to learn cloud security best practices and understand how a simple misconfiguration could compromise your entire environment.

Who’s Who in Cybersecurity: Understanding the Different Types of Threat Actors

Nicolás — Sun, 19 Oct 2025 16:57:49 +0000

Do you automatically picture a person wearing a hoodie, sitting in a dark room, staring at multiple screens filled with green code moving at unreadable speed, like in The Matrix, when you hear the word hacker? Think again.

In the world of cybersecurity, there are many kinds of hackers and digital actors — individuals or groups with different motivations, skills, and goals. Some break into systems for fun or fame, others for money, and some do it with permission to protect people and organizations.

Let’s break down the three main types.

White Hat Hackers (Ethical Hackers)

These are the good guys in cybersecurity. Also known as ethical hackers, White Hats use their skills and knowledge to make the digital world safer for everyone.

They work with permission, helping to identify and fix vulnerabilities before malicious actors can exploit them.

Some examples of what ethical hackers do:

Educate users on how to protect themselves online
Protect organizations’ assets and intellectual property
Safeguard critical infrastructure like power grids or water systems

Black Hat Hackers

Black Hats are what most people picture when they hear the word hacker.

These individuals act maliciously, aiming to steal data, cause damage, or make money through illegal means. Their motivation varies, but it’s often financial gain.

Some examples of what black hat hackers do:

Launch phishing campaigns to steal credentials or access systems
Deploy ransomware to extort money from victims
Blackmail individuals or organizations by threatening to leak data

Gray Hat Hackers

Gray Hat hackers walk the fine line between good and bad. Their actions might come from curiosity or a desire to prove a point.

The key question is what they do after discovering a vulnerability:

Do they report it to the organization privately? (ethical)
Or do they publish it publicly, exposing it to criminals? (unethical)

Gray Hats operate in the space between White and Black Hats — sometimes helping, sometimes harming.

Other Types of Threat Actors

While White, Gray, and Black Hats are the main categories, there are several other types of hackers and threat actors worth knowing about.

Script Kiddies

Script kiddies are beginners with little or no technical experience. They rely on pre-made tools or scripts created by others to launch attacks — often without really understanding how those tools work.

Their motivation is usually curiosity, boredom, or the thrill of “doing something cool”.

Common actions:

Defacing websites using publicly available tools
Launching small-scale denial-of-service (DoS) attacks
Experimenting on insecure systems just to see what happens

While they may seem harmless, they can cause significant damage if they target an insecure system.

Hacktivists

Hacktivists are hackers with a political or social cause. They use their technical skills to make statements, raise awareness, or protest against governments or corporations. However, their actions are often illegal and can cause serious harm.

Some examples of what hacktivists do:

Expose confidential information from governments or corporations
Deface websites to spread political or social messages
Launch denial-of-service (DoS) attacks to disrupt online services of companies they oppose

Their motivation isn’t personal gain — it’s about supporting (or opposing) a specific ideology.

Nation-State Actors

Nation-state actors are hackers backed or funded by governments. They are some of the most advanced and well-resourced threat actors, often involved in cyber espionage, intelligence gathering, or cyberwarfare.

Some examples of what nation-state actors do:

Conduct cyber espionage to steal sensitive government or military data
Disrupt or disable critical infrastructure, such as power grids or communication networks
Spread disinformation or manipulate public opinion during elections

These operations are highly sophisticated and often aim to achieve political or strategic objectives rather than personal profit.

Insider Threats

Not all cyber threats come from outside an organization. Sometimes, the most dangerous ones come from within.

Insider threats involve employees, contractors, or partners who misuse their access — intentionally or accidentally — to harm an organization.

Some examples of what insider threats do:

Leaking confidential data or trade secrets
Sabotaging systems out of revenge or frustration
Selling internal information to competitors or criminals

Because insiders already have legitimate access, detecting them can be especially challenging.

Terrorist Groups

Cyber terrorists use hacking to further violent or extremist goals. Their aim is often to cause fear, chaos, or destruction that supports their cause.

Some examples of what cyber terrorists target:

Critical infrastructure such as transportation or energy systems
Government networks or public services
Businesses or organizations that represent opposing ideologies

These attacks can have devastating real-world consequences, making cyber terrorism one of the most serious digital threats today.

Wrapping Up

Understanding the different types of hackers and threat actors helps us see that cybersecurity isn’t just about firewalls and software — it’s about people and their motivations.

From curious beginners to government-backed espionage groups, each actor plays a different role in the ever-evolving digital landscape.

By learning who they are and why they act, we can take smarter steps to protect ourselves, our organizations, and our communities.