Infrastructure

Command and Control (C2) Infra

Short haul, long haul, persistence, initial access

  • Separate your C2 infra into short haul, long haul, persistence and initial access. Each type should have be as different as the others as possible. This helps keep all your accesses from being burnt with the same IOCs.

    • Different C2 framework (if possible)

    • Different network indicators (malleable c2 profiles, C2 channels)

    • Different loader design (injection technique, packing and obfuscation, file format)

Protect your infra

  • Run all red team infra in a private network, only exposed to the redirectors where necessary

    • Require SSH tunnel or OpenVPN connection into the network to connect to the infra

  • Front facing redirectors should run something with a normal fingerprint e.g. apache/nginx - prevent crawlers and hosting providers from fingerprinting your stuff as malicious

  • Monitor for blue team activity on your infra

    • RedElk

    • RedWarden

    • Check VT for your payload hashes periodically

  • Authenticate every connection e.g. staging. Keep out IR teams etc.

Domains

  • Age your domains

    • Newly registered domains may be an anomaly

  • Submit them for categorization

    • Already categorized domains may get past some filters

  • If you use AWS/Azure serverless for your redirectors you can get a domain from them

    • Might be whitelisted

Command and Control (C2) channels

Malleable C2 profiles

  • Blend in with traffic that is expected to have high traffic frequency - craft your Malleable profiles with reference to existing legitimate traffic.

    • jquery, bootstrap

    • Social media traffic

  • Configure the profile to store the different pieces of data in locations that don't look out of place

    • use requests that already contain base64 e.g. cookies, file upload data etc.

  • Observe your own C2 traffic in a lab and compare it to the legitimate traffic - does it look out of place?

ExternalC2/C3

  • Make use of platforms already in use in the target network

    • Chat apps - teams, slack, discord

    • Trusted services - AWS, Azure etc.

    • Trusted interactions in the target network - shared fileservers etc.

Phishing Infra

Domains

  • Age your domains

    • Newly registered domains may be an anomaly

  • Submit them for categorization

    • Already categorized domains may get past some filters

  • Reconsider putting target organization's name in it directly

    • Some threat intel services will notify the organization if a domain is registered that looks like it could be used for phishing - does the target have one of these services?

Infrastructure

  • Consider using a legitimate service e.g. Sendgrid, Mailgun etc.

  • If self hosting, put the GoPhish etc. behind an SMTP redirector

  • Expect the initial access redirector and artifacts to be burnt early on. Separate them from the rest of your operational infrastructure.

Hosting providers

  • Your infra may be taken down by hosting providers following abuse reports

  • Consider using bulletproof hosting services

    • Less logs (for law enforcement to try to retrieve)

    • Usually ignores abuse reports

    • Due to these reasons, their IP ranges are often blacklisted. Consider running a combination of trusted hosting and bulletproof hosting to secure your core infra while using trusted providers for front facing services.

Useful Links

PreviousWeaponizationNextExample Red Team Infra

Last updated