Most attacks do not begin with malware or exploitation.
They begin with repetition.
The same IP ranges scanning multiple environments.
The same malformed requests probing different endpoints.
The same login failures spaced carefully to avoid alerts.
Attackers test quietly. Defenders who watch patterns instead of alerts see them early.
Common Early Attack Patterns Seen in the Wild
Before compromise, attackers usually leave small, boring signals:
1. Repeated requests to non-existent URLs
2. Authentication attempts across multiple accounts
3. Slow enumeration of parameters or API endpoints
4. Token reuse from unusual locations
5. File uploads that never execute
Individually, these look harmless. Together, they form intent.
Pattern 1: Attacker Endpoint Map and Discovery
Typically, attackers do not understand your application topology. They gain insight into your application's topology by interrogating your application with requests that it was never designed to handle or request to answer. Here’s what they’ll look like:
1. Sequential requests – /api/v1/users /api/v1/admin /api/v2/users
2. Different combination of HTTP methods against the same endpoint
3. Request will generate mostly 404 or 403 responses
Tools Used by Attackers
1. ffuf
2. dirsearch
3. Personal scripts written in Python/curl
Example of a Defender's Investigation
cat access.log | grep -E " 404 | 403 " | awk '{print $7}' | sort | uniq -c | sort -nr | head
This quickly surfaces endpoints that have been tested repeatedly.
Pattern 2: Credential Pressure With No Brute Force
Modern attackers do not conduct noisy brute-force attacks. Instead, they spread their attempts across users, time of day, and IP addresses.
Here’s what they look like:
1. One or two failed logins for every user
2. Multiple users targeted within minutes
3. Rotating IP addresses used over multiple cloud providers
Example of Investigation Using SIEM Logical Aggregation
Pseudo-query of logical aggregation that is used in SOCs:
Count failed logins
Group by source IP and username
Trigger when:
failures < threshold per user
total unique users > threshold
Count unique user login failures. Group the count by source IP and username, and trigger when:
1. Users fail to login less than a threshold and
2. Total unique users fail to login, exceed an established threshold
Example of Analysis Using Linux Based Auth Audit Logs
grep "Failed password" /var/log/auth.log | awk '{print $11}' | sort | uniq -c | sort -nr
Look for IP addresses that touch many users lightly.
Pattern 3: Token Reuse Detection Across Accounts
By leveraging the Python collections library's default dictionaries, we can associate each token's ID with all unique user IDs for each token. Therefore, we can associate all users for which a unique token has been used with their corresponding token, for example.
import collections
token_use = collections.defaultdict(set)
for record in api_logs:
token_use[record["token"]].add(record["user_id"])
for token_id, user_ids in token_use.items():
if len(user_ids) > 1:
print("Suspicious use of token at multiple accounts", token_id)
This basic approach effectively detects both shared tokens (i.e. tokens that are used by multiple users) and stolen tokens (i.e. tokens taken or compromised by unauthorized individuals).
Pattern 4: File Upload Reconnaissance
Before creating malicious files, hackers frequently conduct tests to see if the server can accept these types of files.
Indicators of Early Stage File Upload Recon
1. Uncommon file extensions have been uploaded to the server
2. There are uploaded files that are never subsequently downloaded or accessed
3. There have been multiple attempts to upload files that do not pass validation; so an attack has been attempted many times without success.
Example of a Real Attack
A hacker uploads harmless .txt or .jpg types of files first then attempts to upload .php or .jsp or polyglot file types next.
Example of Hunting for Patterns
find /uploads -type f -mtime -1 ! -name "*.jpg" ! -name "*.png"
Indicates Files Not Stored On the Server According to Normal File Extension Types at an Early Date
Pattern 5: Infrastructure Fingerprinting
Attackers Fingerprint Your Stack Before Stealing Exploits.
Common Infrastructure Fingerprinting Signals
1. Server status requests sent to the /server-status endpoint (typically indicates a system diagnostics page)
2. Probing for access to the .env, .git, and/or /actuator endpoints (common steps attackers will take to gather more data regarding your application)
3. Determining Environment Variables and access point signatures by analyzing Repeated HEAD Requests (this can indicate an active attempt at attacking the application)
Tooling Seen
1. Nmap scripts
2. httpx
3. Custom Python Requests
Example: Identifying Suspicious HEAD Requests
grep " HEAD " access.log | awk '{print $1}' | sort | uniq -c | sort -nr
Traffic Heavy in HEAD is not usually Legitimate
Older alerting methods trigger after exploitation whereas hunting for patterns begins much earlier, before exploitation. Attackers rely on defenders to ignore "noise" within the logs and therefore only see the apparent signal. However, if the noise from the logs is aggregated correctly, patterns can form allowing for early detection of potential attacks.
By recognizing these patterns, security professionals can enact controls that will prevent these types of attacks. Examples include blocking the IP ranges of the scanning hosts, limiting the amount of requests to specific endpoints, locking user accounts after several failed login attempts from around the world, and alerting on behaviors rather than just signature-based alerts. All of these methods have been demonstrated to reduce an attacker's dwell time significantly.
There are a number of things that security teams need to remember when hunting for patterns to protect against attacks:
1. Most attacks will rehearse before they execute.
2. The logs provide excellent indicators of early warning signs.
3. Simple scripts can help identify the patterns that security tools often overlook.
4. Pattern-based hunting will reduce the element of surprise.
When discussing prevention through patterns, the term "prevention" does not always refer to "blocking" an attack but rather making it possible to "see" it first.
