How attackers think: the attacker mindset

Security is not about tools. It is about understanding how attackers think, what they want, and how they get it. Every firewall rule, every password policy, every security patch exists because someone found a way to exploit the system without it. If you want to defend effectively, you need to learn to see your systems the way an attacker does.

Who are the attackers?

Not all attackers are the same. Their skill, motivation, and resources vary widely:

Script kiddies use pre-built tools and scripts without understanding how they work. Low skill, high volume. They scan the internet looking for known vulnerabilities and unpatched systems. Most automated attacks you see in your logs come from this group.

Hacktivists are motivated by ideology or politics. They deface websites, leak data, or disrupt services to make a point. Their technical skill ranges from low to moderate.

Cybercriminals are motivated by money. Ransomware, data theft for sale on dark markets, business email compromise, credential stuffing. They are organized, persistent, and often operate as businesses with customer support for their ransomware victims.

Advanced Persistent Threats (APTs) are nation-state or state-sponsored groups. They target specific organizations, have significant resources, and are willing to spend months or years on a single target. They develop custom tools and zero-day exploits.

Insiders are employees, contractors, or partners who misuse their legitimate access. They are the hardest to detect because their actions look like normal work until they do not.

The attack lifecycle

Every attack, from a simple website defacement to a multi-year espionage campaign, follows a lifecycle. Understanding this lifecycle tells you where to put your defenses.

graph LR
  A[Reconnaissance] --> B[Initial Access]
  B --> C[Establish Foothold]
  C --> D[Privilege Escalation]
  D --> E[Lateral Movement]
  E --> F[Persistence]
  F --> G[Data Exfiltration / Impact]
  style A fill:#64b5f6,stroke:#1976d2,color:#000
  style D fill:#ffb74d,stroke:#f57c00,color:#000
  style G fill:#ef5350,stroke:#c62828,color:#fff

1. Reconnaissance

The attacker gathers information about the target. What technology do they use? What domains and subdomains exist? Who works there? What is exposed to the internet?

This phase is covered in detail in Reconnaissance and OSINT.

Passive recon does not touch the target: WHOIS lookups, DNS records, LinkedIn profiles, GitHub repos, job postings (which reveal technology stack).

Active recon interacts with the target: port scanning, directory brute-forcing, sending crafted requests.

2. Initial access

The attacker gets in. Common methods:

• Exploiting a web application vulnerability (SQL injection, RCE)
• Phishing an employee to get credentials
• Exploiting a known CVE on an unpatched service
• Brute forcing SSH or other login services
• Using stolen credentials from a previous breach

3. Establish foothold

Once in, the attacker creates a reliable way to get back. This might be a reverse shell, a web shell uploaded to the server, or a cron job that connects back to their infrastructure.

4. Privilege escalation

The attacker landed as a low-privilege user. They need root or admin to do real damage. They look for misconfigurations, SUID binaries, writable scripts, kernel exploits, or credentials left in files.

5. Lateral movement

Once they have elevated privileges on one system, they move to others. They dump credentials, scan the internal network, and exploit trust relationships between systems.

6. Persistence

The attacker ensures they can survive reboots, password changes, and discovery of their initial entry point. Multiple backdoors across multiple systems. This is covered in Post-exploitation and persistence.

7. Data exfiltration / Impact

The final goal. This could be stealing data, deploying ransomware, destroying systems, or silently monitoring communications.

Why defenders need to think offensively

If you only think about defense, you build walls and hope they are high enough. If you think like an attacker, you look at your walls from the outside and find the gaps.

Practical example: you set up a web server with a firewall that blocks everything except ports 80 and 443. You feel secure. An attacker looks at this and thinks: “Port 80 is open. What is running on it? Does it have a login page? Can I brute force it? Does it run a framework with known CVEs? Is there a directory listing? An exposed admin panel?”

The firewall is one layer. The attacker goes through the allowed opening and attacks the application itself.

Example 1: Thinking through a real scenario

You are defending a small company with:

• A public website on Ubuntu, running Nginx and a Node.js app
• An internal PostgreSQL database
• 5 employees with SSH access
• No security team

Think like an attacker:

Recon phase: Search the company name online. Check DNS records for subdomains. Look at the website source code for framework versions. Check GitHub for any public repos (do they accidentally commit credentials?). Look at LinkedIn for employee names and their tech stack.

# What an attacker would run
dig company.com any
dig +short company.com MX
dig +short company.com TXT
nslookup -type=NS company.com

Initial access ideas:

1. The Node.js app might have a vulnerability (check the framework version)
2. SSH is probably exposed to the internet (check with a port scan)
3. Employees might reuse passwords from leaked databases
4. The website might have a login form vulnerable to brute forcing

What the defender should do:

1. Keep the Node.js app and all dependencies updated
2. Restrict SSH access to specific IPs, use key-based auth, install fail2ban
3. Require MFA for all logins (see Authentication)
4. Rate-limit login attempts on the web app
5. Move the database to a private network with no public access
6. Set up log monitoring and alerts

Example 2: Mapping the attack surface

An attack surface is everything an attacker can interact with. Let’s map one for a typical web server:

# Network attack surface: what ports are open?
nmap -sV 192.168.1.100

Output (in a lab context):

PORT     STATE SERVICE  VERSION
22/tcp   open  ssh      OpenSSH 9.3p1 Ubuntu 1ubuntu3.6
80/tcp   open  http     nginx/1.24.0
443/tcp  open  ssl/http nginx/1.24.0
5432/tcp open  postgresql PostgreSQL 16.3

Analysis:

• SSH is open: good for admin, but also for brute forcing. Reduce: restrict to specific IPs.
• HTTP/HTTPS: necessary, but the web app behind it is attackable. Reduce: keep app patched, add WAF.
• PostgreSQL is exposed to the network: Reduce: bind to 127.0.0.1 only, not 0.0.0.0.

# Application attack surface: what does the web app expose?
curl -s https://company.com/robots.txt

Output:

User-agent: *
Disallow: /admin/
Disallow: /api/internal/
Disallow: /backup/

The robots.txt just told the attacker there is an admin panel, an internal API, and a backup directory. These are now targets.

# Check HTTP headers for information leakage
curl -sI https://company.com

Output:

HTTP/2 200
server: nginx/1.24.0
x-powered-by: Express
set-cookie: session=abc123; Path=/

The x-powered-by: Express header tells the attacker this is a Node.js Express application. They now know exactly what vulnerabilities to look for.

Defender’s fix: Remove information-leaking headers:

# In nginx config
server_tokens off;

# In Express app
app.disable('x-powered-by');

The security mindset in daily work

Thinking like an attacker is not something you do once. It is a habit:

• When you deploy a new service, ask: “How would someone abuse this?”
• When you write an API, ask: “What happens if someone sends unexpected input?”
• When you grant access, ask: “What could this person (or their compromised account) do?”
• When you read a log entry, ask: “Could this be an attacker’s action disguised as normal behavior?”

What comes next

The next article covers Networking fundamentals for security, where you will learn the protocols that make the internet work and what they reveal to attackers.

If you want to start with the defender’s toolkit, check out Linux security basics from the Linux series for practical hardening steps.