Guides & Learning
SOC L1 Hands-on Interview Questions with Answers
L1 Interview

Senior Hosting Security Engineer

A compromised website could be used to steal data, send spam, deploy malware, or attempt to access other customers' files. I would identify the affected account, investigate the entry point, and check for privilege escalation or cross-account access. I would rely on account isolation, least-privilege permissions, resource limits, and monitoring to contain the compromise. If isolation is breached, I would escalate it as a platform-level incident because other customers may be at risk.
Shared hosting places multiple customers on the same server, so strong account isolation is essential. A VPS provides a virtual machine boundary, while dedicated hosting gives a customer a physical server. Containerised hosting isolates workloads using operating-system-level mechanisms, but containers still share the host kernel. I would choose controls based on the threat model, tenant isolation requirements, and the impact of a compromise.
cPanel lets customers manage their hosting accounts, while WHM lets administrators manage multiple accounts and hosting configurations. CloudLinux LVE limits resource consumption such as CPU, memory, and I/O. CageFS restricts what a hosting account can see in the filesystem. Together, these controls help reduce resource abuse and cross-account exposure, but they must be combined with correct permissions, patching, and monitoring.
I would treat this as a potential tenant-isolation failure. I would validate the affected paths, account identities, permissions, symlinks, and relevant web-server configuration. Then I would determine whether the exposure is limited to one account or affects the wider hosting node. I would preserve evidence, restrict access where necessary, and involve the platform team to investigate the isolation boundary before declaring the incident resolved.
A website administrator may control a single application, whereas a hosting control-panel account may also manage files, databases, email, domains, SSL certificates, SSH access, and scheduled tasks. The actual impact depends on the platform's permissions. I would investigate the account's access level, review login and configuration-change logs, revoke sessions, rotate affected credentials, and check whether the attacker modified other services or websites.
I would first identify the processes using top, ps, and pstree, then inspect their command lines, executable paths, owners, and network connections using ss or lsof. I would review authentication logs, scheduled tasks, and recent file changes. I would correlate these findings with EDR and network telemetry to determine whether this is a cryptominer, legitimate workload, or another compromise. If malicious, I would contain the server and investigate the initial access and scope.
I would preserve the file and calculate its hash using sha256sum. I would check its file type using file, inspect readable strings, and examine ELF metadata with tools such as readelf. I would correlate its execution with process, authentication, and network logs, and use a controlled sandbox if deeper behavioural analysis were required. I would avoid executing an unknown binary directly on a production server.
SUID allows an executable to run with the effective user ID of its owner, often root. A vulnerable or misconfigured SUID binary can allow privilege escalation. I would review unusual SUID files with find / -perm -4000 -type f 2>/dev/null, verify whether they are expected, and investigate their ownership, permissions, integrity, and execution history.
I would review /var/log/auth.log or /var/log/secure, depending on the distribution, for successful and failed logins, source IPs, and authentication methods. I would inspect SSH configuration and authorised keys, shell history, running processes, network connections, cron jobs, and recently modified files. I would correlate these with EDR and SIEM telemetry to establish how access was obtained, what the attacker did, and whether other systems were accessed.
I would compare the initial access account with the privileges obtained and look for suspicious sudo activity, unusual SUID executables, writable scripts, modified services, kernel exploitation indicators, and unexpected root processes. I would review authentication and audit logs and reconstruct the execution timeline. I would then validate the suspected vulnerability or misconfiguration and remediate the root cause, rather than simply deleting the suspicious file.
I would inspect the website's files, database content, web-server configuration, redirects, and recently modified files. I would review access logs for suspicious requests, exploit attempts, and unusual administrative activity. I would also check WordPress plugins, themes, administrator accounts, and scheduled tasks. After identifying the injection or compromised component, I would remove the malicious changes, patch the entry point, rotate affected credentials, and verify that the redirect no longer occurs.
I would look for suspicious functionality such as command execution, arbitrary file uploads, encoded payloads, or requests that execute system commands. I would compare the file against a trusted application version, inspect its modification history and ownership, and correlate access logs with execution. A suspicious function alone does not prove maliciousness; I would use the surrounding code, file provenance, and observed behaviour to make the decision.
A web shell is a malicious script that gives an attacker remote control through a web server. I would preserve the file and its metadata, identify how it was uploaded, and review web logs and process telemetry for commands executed through it. I would contain the affected site or account where appropriate, remove the shell after evidence preservation, patch the initial vulnerability, rotate compromised credentials, and hunt for related activity across other hosted sites.
I would identify the plugin and version, check whether the relevant vulnerability is applicable, and examine web logs for exploit attempts. Then I would inspect PHP files, WordPress administrator accounts, database content, scheduled tasks, and outbound connections. I would remove malicious changes, update or disable the vulnerable plugin, reset affected credentials, and check whether the attacker created persistence or accessed other customer data.
Magecart refers to attacks that inject malicious JavaScript into websites to steal payment or checkout data. I would inspect checkout-page scripts, third-party dependencies, unexpected changes to JavaScript files, and connections to unfamiliar domains. File-integrity monitoring, Content Security Policy, browser-side monitoring, and web-server logs can help detect this activity. If confirmed, I would remove the injection, investigate how it was introduced, and assess whether payment data may have been exposed.
I would identify the phishing files and domains, inspect the hosting account and web-access logs, and determine how the kit was uploaded. I would check whether the account was compromised or abused intentionally, and look for credential collection, email-sending activity, and connections to other malicious infrastructure. I would coordinate suspension or restriction of the malicious content, preserve evidence, remediate the access path, and check for other phishing pages hosted on the same platform.
I would check DNS resolution first using dig or nslookup, then verify the A/AAAA and CNAME records, nameservers, and DNS propagation. If DNS resolves correctly, I would inspect the virtual-host configuration, reverse proxy, TLS certificate, and HTTP response. I would also check whether the application is listening on the expected interface and port. This separates DNS issues from web-server, TLS, and application problems.
I would compare traffic volume against historical baselines and analyse request rates, source distribution, protocol patterns, endpoint concentration, and response codes. I would check whether traffic comes from a large number of sources or repeatedly targets a specific resource. I would correlate CDN, WAF, load-balancer, and server metrics. If it is an attack, I would coordinate rate limiting, WAF rules, CDN mitigation, or upstream filtering while monitoring service availability.
I would check the certificate's subject names and SANs, expiration, certificate chain, server time, SNI configuration, and whether the CDN or reverse proxy is serving a different certificate from the origin. I would test the hostname and inspect the TLS handshake. I would also verify certificate renewal and deployment processes, because a valid certificate on one server does not guarantee every endpoint is presenting the correct certificate.
I would ensure registrar and DNS-provider accounts use MFA, restrict access, and monitor record changes. I would configure DNSSEC where supported and implement SPF, DKIM, and DMARC for email authentication. I would also monitor newly created subdomains, suspicious DNS changes, and domain reputation. These controls address different risks: DNSSEC protects DNS response integrity, while SPF, DKIM, and DMARC help reduce email spoofing.
I would not rely on the scanner verdict alone. I would examine the file hash, code, source, modification time, execution history, and surrounding activity. I would check threat intelligence and compare the file with a trusted version. If the evidence supports legitimate activity, I would document the reasoning and consider a narrowly scoped exception. If malicious behaviour is present, I would contain and remediate it regardless of the customer's initial assessment.
I would investigate sustained CPU usage, unfamiliar processes, unexpected outbound connections, and connections to known mining pools. I would check process paths, parent processes, cron jobs, systemd services, temporary directories, and recent file changes. I would correlate the indicators with EDR and network logs. Once confirmed, I would contain the workload, remove the miner and persistence, investigate the initial access, and hunt for the same indicators across other servers.
I would group requests by source IP, URI, HTTP method, response code, user agent, and time. Requests for common sensitive paths or many different endpoints may indicate reconnaissance; exploit payloads followed by unusual process execution or file creation may indicate successful exploitation. I would correlate web logs with application, authentication, and EDR telemetry to establish whether the attacker merely probed the server or gained execution.
I would identify the attacker behaviour rather than relying only on a single hash or IP. For example, for a web-shell attack, I could correlate unusual PHP file creation with suspicious web requests and a web-server process spawning a shell. I would test the logic against known malicious and legitimate activity, tune false positives, map the detection to MITRE ATT&CK, and monitor its performance after deployment.
I would validate the exposure, identify the affected bucket and data, and restrict public access immediately using the appropriate bucket or account-level controls. Then I would review bucket policies, ACLs, CloudTrail events, access logs, and relevant IAM activity to determine how the exposure occurred and whether data was accessed. I would preserve evidence, assess the impact with the data owner, remediate the misconfiguration, and implement preventive monitoring.
I would review CloudTrail for the role assumption event, source identity, source IP, user agent, session details, and subsequent API calls. I would check whether the activity matches the role's expected permissions and normal usage. I would correlate it with GuardDuty findings, VPC Flow Logs, and other relevant telemetry. If compromise is suspected, I would revoke or restrict the session and permissions as appropriate, then investigate what resources were accessed or changed.
Containers share the host kernel, so risks include vulnerable images, excessive privileges, exposed secrets, insecure mounts, and weak network isolation. I would inspect container image provenance, runtime process activity, privileges, mounted volumes, network connections, and orchestration events. I would also investigate the host, because a container compromise can become a host-level incident if isolation is bypassed. I would contain the workload and rebuild from a trusted image after determining the root cause.
I would explain the risk and the need to preserve evidence. If the threat is active, I would prioritise containment—such as restricting access or isolating the affected workload—while preserving the file, its hash, timestamps, ownership, and relevant logs. I would coordinate with the customer and incident-response team, then remove the file when evidence preservation and containment requirements are satisfied.
I would first establish the affected account, the attacker's access level, and whether tenant isolation remains intact. If possible, I would restrict the affected account or site rather than taking down the entire node. I would investigate cross-account access, shared services, and resource abuse, while monitoring neighbouring tenants for the same indicators. If the platform boundary is at risk, I would escalate containment to the node or platform level and communicate the potential customer impact.
I would assess exploitability, internet exposure, asset criticality, available exploit code, active threat intelligence, and the potential impact of compromise. I would identify vulnerable versions and prioritise exposed, business-critical systems first. I would coordinate mitigations or patching, use compensating controls where immediate patching is not possible, and validate remediation through rescanning and configuration checks. I would also hunt for exploitation indicators because the absence of confirmed incidents does not mean the vulnerability has not been exploited.
Continue reading
Guides & Learning
L1 Interview

Guides & Learning
Part 1

Guides & Learning
what it actually means, why it matters, the different fields within it, and how to start learning - Rohith Hari

3 entries, most recent posts.
Cybersecurity researchers have uncovered an AI-assisted cybercrime operation attributed to CyberXero, a financially motivated initial access broker th...

The convergence of Operational Technology (OT), the Internet of Things (IoT), and traditional enterprise IT networks is transforming how organisations...

Smart cameras are widely used in homes, offices, retail environments, warehouses, and industrial facilities. Their connectivity enables remote monitor...
