Interview Q&A — C2 Infrastructure, Cloud, & Social Engineering

Phases 08–10: C2 architecture, beacon OPSEC, redirectors, JA3/JA4, cloud IAM attack paths, IMDS, container escape, email authentication, and OSINT-based initial access.

C2 Infrastructure (Phase 08)

Q: Walk me through a production C2 architecture. What is the purpose of each component?

Answer outline:

Operator workstation → Team server → Redirector(s) → Internet → Implant (beacon) on target
  • Team server: the C2 platform (e.g., Cobalt Strike, Mythic, Havoc). It stores beacon configs, manages sessions, receives check-in traffic, and allows operators to issue tasks. Lives on a hardened, non-attributable server. Never exposed directly to the target.
  • Redirector: a lightweight proxy (Apache/Nginx with mod_rewrite, an AWS API Gateway, a CDN endpoint) between the internet and the team server. Its job: forward traffic matching the beacon's malleable profile URI to the team server, and serve legitimate-looking 404s or decoy pages to everything else. Protects the team server's IP from being burned by a proactive block.
  • Implant (beacon): the agent running on the target. Check-in on a configured interval with jitter, over HTTPS to the redirector. Executes tasks received from the team server.

The traffic chain: implant → redirector domain (looks like CDN/legitimate domain) → redirector → team server. If the client's security team burns the redirector domain, the team server IP is not revealed. The redirector is disposable; the team server is protected.

Q: What is a JA3/JA4 fingerprint and how does it detect C2 beacons?

Answer outline:

JA3 is an MD5 of a TLS ClientHello's key fields in a specific order: SSLVersion, Ciphers, Extensions, EllipticCurves, EllipticCurvePointFormats. Two TLS clients that use the same TLS library version and configuration produce the same JA3 hash. Cobalt Strike's default configuration produces a well-known JA3 that is in public detection databases.

JA4 (newer) captures more fields and is more granular, including cipher order and extension details. It is case-sensitive and order-aware.

Detection: a network sensor (Zeek, Suricata) records the JA3 hash for every TLS ClientHello. A rule matching against a known-bad JA3 database fires. A beacon with a default TLS configuration will match.

Mitigation: changing the cipher suite order or TLS version in the C2 malleable profile changes the JA3 hash. But changing cipher suites is observable via a JA4 rule update; the behavioral pattern (periodic connection from an unusual process at a regular interval) remains. JA3 sits at the "network artifact" layer of Bianco's pyramid — not the most durable detection, but easy to implement and effective against unmodified default tooling.

Q: How do you detect a C2 beacon in NetFlow data without endpoint telemetry?

Answer outline:

Beacon detection in NetFlow is a signal-processing problem on inter-connection timing:

  1. Beacon interval extraction: for each source IP + destination IP pair, compute the inter-connection timestamps. A beacon at 60-second sleep produces inter-connection gaps near 60s.
  2. Jitter coefficient (CV): compute the coefficient of variation (stddev/mean) of the gaps. A well-configured beacon with 20% jitter has CV ≈ 0.2. A poorly configured beacon with 0% jitter has CV ≈ 0 (perfectly regular).
  3. Process anomaly: correlate the source with EDR process data (if available). A periodic connection from svchost.exe or explorer.exe to an external IP that is not a CDN or Windows Update server is anomalous.
  4. Long-connection detection (Zeek): some beacons maintain a long-lived HTTP connection and poll; Zeek's conn.log duration field flags connections longer than the normal session duration for that service.

A SIEM rule: connections from the internal network to a new external IP, at a coefficient of variation below 0.1, for more than 5 consecutive observations, that are not from a known-good process → beacon alert.

Cloud & Container (Phase 09)

Q: Explain the AWS IAM policy evaluation order. Why does "deny always wins" matter for privilege escalation?

Answer outline:

AWS evaluates IAM policies in this order when a principal makes an API call:

  1. Explicit deny (any policy type) — if any policy has an explicit Deny for this action, the request is denied immediately, regardless of any Allow.
  2. SCPs (Service Control Policies) — organization-level deny; if the SCP does not allow the action, the request is denied even if the identity policy allows it.
  3. Resource-based policies — if the resource has a policy that allows the action for this principal, it is allowed (even without an identity policy, for cross-account).
  4. Identity-based policies — if none of the above denies and the identity policy allows the action, it is allowed.
  5. Implicit deny — if no Allow matches, the request is denied by default.

Why this matters for privilege escalation: the AWS IAM privilege escalation paths (documented by Rhino Security Labs) rely on finding a principal that has iam:PassRole plus the ability to create a Lambda/EC2/ECS resource. The attacker passes a high-privileged role to the resource, then triggers the resource to execute — giving them the high-privileged role's permissions without ever having an explicit Allow on the sensitive action directly.

The defense: SCPs that deny iam:PassRole to non-admin principals; and detection: CloudTrail logs all iam:PassRole calls. A non-admin principal calling iam:PassRole with a high-privileged role is immediately suspicious.

Q: What is the AWS IMDS and why is IMDSv1 dangerous?

Answer outline:

The Instance Metadata Service (IMDS) is an HTTP endpoint available from within an EC2 instance at http://169.254.169.254/. It provides instance metadata including the IAM role credentials assigned to the instance (/latest/meta-data/iam/security-credentials/role-name).

IMDSv1 is accessible without any token or authentication — a simple GET request from inside the instance returns the credentials. If a web application running on the EC2 instance is vulnerable to SSRF (Server-Side Request Forgery), an attacker can route a GET request to http://169.254.169.254/latest/meta-data/iam/security-credentials/ and receive valid, time-limited AWS credentials for the instance's role.

IMDSv2 requires a PUT request to first obtain a session token (X-aws-ec2-metadata-token), which must be included in subsequent GET requests. SSRF via HTTP typically cannot make PUT requests (browser CSRF constraints), making IMDSv2 resistant to SSRF-based credential theft.

Detection: CloudTrail does not log IMDS requests (it is not an API call). The detection is at the application layer: the web application's access log shows a request with a url parameter or redirect pointing to 169.254.169.254; or a WAF rule blocking SSRF to the IMDS range.

Defense: enforce IMDSv2 via EC2 instance metadata options (HttpTokens=required).

Q: Name three container escape paths and the detection for each.

Answer outline:

  1. Privileged container (--privileged). A privileged container receives all Linux capabilities including CAP_SYS_ADMIN. From inside, mount the host filesystem: mount /dev/sda1 /mnt → chroot → full host access. Detection: Falco rule: spawned_process and container.privileged=true → alert on any process spawned in a privileged container. Or runtime policy: deny privileged container creation in the admission controller (OPA Gatekeeper, Kyverno).

  2. Docker socket mounted (/var/run/docker.sock). If the container has the Docker socket mounted (common in CI/CD runners and monitoring containers), the container can run docker run -v /:/host ubuntu chroot /host to get a root shell on the host. Detection: runtime check — scan container specs for /var/run/docker.sock volume mount. Falco: fd.name=/var/run/docker.sock and evt.type=open.

  3. cap_sys_admin capability. With CAP_SYS_ADMIN, the container can create a user namespace, mount filesystems, and use cgroups_v1 release agent escape. Detection: Falco rule keyed on cap_sys_admin in container + mount syscall. Kubernetes admission webhook: reject pods with securityContext.capabilities.add: SYS_ADMIN.

Social Engineering & Initial Access (Phase 10)

Q: Explain SPF, DKIM, and DMARC. What happens when all three fail?

Answer outline:

SPF (Sender Policy Framework): a DNS TXT record at domain.com listing authorized sending IP addresses/ranges. The receiving MTA checks whether the sending server's IP is in the SPF record. A ~all (soft fail) or -all (hard fail) controls what happens on mismatch. SPF checks the MAIL FROM envelope address, not the From: header.

DKIM (DomainKeys Identified Mail): the sending mail server adds a cryptographic signature (RSA or Ed25519) over specified headers and body. The public key is published in DNS at selector._domainkey.domain.com. The receiving MTA verifies the signature. DKIM proves the message was authorized by the domain's key holder and was not modified in transit.

DMARC (Domain-based Message Authentication, Reporting, and Conformance): a DNS policy at _dmarc.domain.com that says: (a) what to do when SPF and/or DKIM fail (p=none|quarantine| reject), (b) what alignment is required (strict: the From: domain must exactly match the SPF/DKIM domain), (c) where to send aggregate reports (rua=mailto:...).

When all three fail: the receiving MTA applies the DMARC policy. If p=reject, the email is rejected. If p=quarantine, it goes to spam. If p=none (monitoring mode), it is delivered with a warning. A phishing email spoofing a domain with p=none; is delivered — which is why many organizations stay in monitoring mode indefinitely and are phishable via their own domain.

Phish risk score implications: SPF fail + DKIM fail + DMARC p=none = deliverable spoofed email with no enforcement. The Lab 01 phish-risk scorer returns a high score for this combination.

Q: You need to OSINT a target org for a social engineering pretext. Walk me through your methodology.

Answer outline:

Step 1 — Organizational structure. LinkedIn: org chart, headcount, key roles (who is the CISO, who is in IT, who manages finance). Job postings: what technology stack they are deploying (a "Senior Salesforce Admin" posting means Salesforce is in scope for vendor impersonation).

Step 2 — Email pattern. GitHub commit emails, bug tracker posts, conference talk bios often expose individual email addresses. From 3–5 examples, infer the pattern (first.last@domain.com, flast@domain.com). Validate against the domain's MX records.

Step 3 — Infrastructure. Certificate Transparency logs (crt.sh) for subdomains. Shodan for exposed services. staging.domain.com, admin.domain.com, vpn.domain.com naming patterns expose infrastructure worth targeting in a pretexting call.

Step 4 — Technology stack. Job postings, GitHub, BuiltWith, Wappalyzer. Knowing they use Okta, Office 365, and Workday tells you what vendor impersonation angles (Microsoft, Okta) and what phishing lure formats (Okta sign-in page, SharePoint notification, Workday update) would be most plausible.

Step 5 — Recent events. Press releases, LinkedIn posts about expansions/acquisitions, SEC filings. A merger creates a "new IT policy requiring credential verification" pretext. A public breach creates a "security team reaching out to verify your account" pretext.

Detection by the defender: email gateways log SPF/DKIM/DMARC results (Lab 01 analyzes these). Security awareness training programs monitor reported phishing. DNS monitoring for lookalike domains (meridianfreight-security.com vs meridianfreight.com).