Red team assessment services
A red team assessment is an objective-led simulation of a real adversary: instead of listing every weakness, it tries to reach a goal you agree in advance, such as a named dataset or control of the domain, and shows whether your monitoring and your people notice. BERRY9 plans each exercise with written rules of engagement and a small control group on your side, working from Hyderabad for organizations across India.
- Approach
- Objective-led adversary simulation
- Measures
- Detection and response, not only weaknesses
- Controls
- Written rules of engagement and a white cell
- Starts from
- INR 27,000 + 18% GST
Last reviewed
Illustrative One red team exercise, from agreement to debrief
Before
Goal and rules signed
An objective, the routes allowed, a white cell and the stop conditions, agreed in writing.
During
Quiet pursuit, logged
The red team works toward the goal while your defenders go about a normal week.
After
Story set against alerts
Each step is matched with what monitoring saw, to show where detection held and where it slipped.
Example flow, not a client engagement.
01 / Red team or pentest
Red teaming vs penetration testing
A penetration test asks where the weaknesses are. A red team asks whether a real adversary could reach a real objective, and whether anyone on your side would notice before it got there.
People often use the two names for the same thing, yet they are built to answer different questions and they suit different organizations. A penetration test is a coverage exercise: testers who know what is in scope, usually with accounts you provide and in the open with your security team, try to find as many weaknesses as they can in a set of applications, hosts or a domain before the window closes. A red team exercise is a simulation of an adversary with a purpose. It starts from a goal, such as a particular set of records, an administration panel or control of your Windows domain, and works quietly toward it by whatever routes the agreed rules allow, while the people defending you are not told it is happening.
| Question | Penetration test | Red team exercise |
|---|---|---|
| What it asks | Where are the weaknesses in these assets? | Could an adversary reach this goal, and would we notice in time? |
| What is in scope | A list of applications, hosts, networks or a domain | An objective, plus the routes toward it that the rules of engagement permit |
| Who knows | Your IT and security staff, who often help with access | A small control group; the defenders work as they would on any other day |
| How it behaves | Thorough and open, aiming to cover everything in scope | Selective and quiet, aiming to look like a real intruder |
| What success looks like | A complete, ranked list of findings with fixes | A clear answer on the objective, and a record of what was seen along the way |
| When it fits | Before launch, before audits, after big changes, and at least once a year | When monitoring and a response process exist and need testing under realistic pressure |
A red team is not a stronger penetration test. An exercise that reaches its goal by one route tells you little about the other routes it never tried. If you need to know everything that is wrong with an application or a network, that is the penetration test's job, and it stays on the calendar after a red team.
At BERRY9 the penetration test is the default engagement, and a red team is something we scope with you deliberately. There is also a middle ground: one goal can be written into an ordinary penetration test, for example getting from the open internet into an administration panel without any account to begin with. That gives you a single realistic path tested within the penetration test's own scope. A full red team, covert, spread over a longer window and able to include people as well as systems, is a separate scope with its own proposal. Every kind of test we run is listed in our offensive security services overview.
02 / Readiness
When you are ready for a red team, and when you are not
A red team exercise tests your ability to detect and respond. If nothing is watching yet, it mostly confirms what a penetration test would have found for less.
Signs that a red team will be money well spent:
Penetration tests are a habit
Your applications and networks have been tested before and most findings are closed, so the obvious ways in are gone and the exercise has to work for its result.
Someone is watching the alerts
An in-house security operations team, a managed detection provider or an on-call engineer reviews alerts and can escalate. That capability is what the exercise measures.
A response plan exists on paper
You have an incident response process and want to know whether it works when nobody has warned the people who must follow it.
Signs that a penetration test should come first:
No recent independent test
Without a baseline, a red team mostly rediscovers what a cheaper test would list in full. Start with a web application penetration test or a network penetration test and come back once the findings are fixed.
Known findings are still open
If last year's report lists weaknesses nobody has fixed, the red team will simply walk through them. Close them first, then ask whether anyone would spot a determined intruder.
Logs are not collected or read
When nothing records sign-ins, server activity or cloud changes, there is no detection to evaluate. The result would be a long list of things nobody saw, which you can predict without paying for it.
Most organizations do not need a red team yet, and we will say so. Tell us what testing you have had and how your alerts are handled, and we will help you decide whether a red team or a penetration test is the better use of the budget.
A red team does not stand in for the testing an audit framework looks for. If the goal is evidence for an ISO 27001 certification or a PCI DSS assessment, begin with penetration testing for ISO 27001 or penetration testing for PCI DSS, and keep the red team for when that groundwork is done.
03 / Objectives and scenarios
Objectives and scenarios, agreed before anything starts
Every exercise is built around a goal written down in advance. The goal decides what success means for the red team; the scenario decides where it begins.
Show details for Objectives and scenarios, agreed before anything starts
Typical objectives, each one written down before the exercise starts:
A named set of records
Customer data in one database, design files on one share, payroll in one system. Exercises commonly prove success with a planted marker file or a harmless sample, so real data does not have to leave your network.
An administration panel
A payments back office, a production console or the dashboard that runs your plant floor: a place where one account can do a great deal of damage.
Control of the domain
Administrative rights over Windows Active Directory, which in most companies means control of almost everything else. A dedicated Active Directory test maps every such path; a red team shows whether one can be walked unnoticed.
A production cloud account
Administrative control of the AWS, Azure or Google Cloud account that hosts your product. A cloud security assessment reviews that account's configuration as a whole.
Starting points the scenario can use:
- From outside, with nothing. The red team begins where any stranger on the internet begins, with public information about your company, its domains and its staff.
- From an assumed foothold. You hand over a staff laptop or a standard account, which skips the question of getting in and spends the time on what happens after an initial compromise.
- Through people. Phishing emails or pretext phone calls form part of the route, only with written authorization and rules that name who may be contacted and how. The social engineering assessment page covers people-focused testing on its own.
- Physical access. Physical access testing of offices and sites is not part of BERRY9's red team engagements.
Scenarios are most useful when they resemble the adversaries your sector actually meets. A payments company, a drug manufacturer and a software exporter worry about different attackers with different goals, so the objective and the starting point are chosen from your own risk picture rather than from a standard menu.
04 / Rules of engagement
Rules of engagement, the white cell and stop conditions
A red team may behave like an attacker only inside limits that are agreed and signed first. These limits are standard professional practice for adversary simulation, and they are what separate an authorized exercise from an attack.
Show details for Rules of engagement, the white cell and stop conditions
- Written authorization. Signed by someone with the authority to approve testing of every system, account and location in scope. Where a third party runs part of the estate, such as a hosting provider, an outsourced IT firm or a shared building, its terms or consent are checked as well.
- Scope and exclusions. Which systems, people and places are in, which are out, the hours when activity is allowed, and actions that are off the table whatever happens.
- The white cell. A small control group on your side, often a senior security lead and an executive sponsor, who know the exercise is running, approve any change of route and handle surprises. They do not tip off the defenders.
- Deconfliction. When your defenders spot something and escalate it, the white cell can confirm quickly whether it is the exercise. That keeps a real intrusion from being waved away as the red team, and keeps the exercise from being reported outside as a real incident.
- Stop conditions. Agreed triggers that pause or end the work: signs of a genuine attacker, access to data more sensitive than planned, a system that becomes unstable, a person who is distressed, or simply a request from the white cell.
- Evidence and clean-up. What the red team may copy as proof, how that proof is stored and destroyed, and a record of anything it placed in your environment so it can be removed afterwards.
Rules of engagement do not promise that nothing can go wrong on a live network. They settle in advance who decides, how fast the exercise can be paused, and what happens next if it is.
05 / Method
How a red team engagement runs
Seen from your side, an exercise involves three groups: the red team, the white cell that knows, and the defenders who do not. The table shows what each does in each phase.
Show details for How a red team engagement runs
| Phase | Red team | White cell | Defenders |
|---|---|---|---|
| Planning | Proposes objectives and scenarios based on your sector and estate | Signs the authorization, sets exclusions and stop conditions | Not told; business as usual |
| Reconnaissance | Learns what an outsider can find about your people, domains and technology | Receives short progress notes | Often see nothing, since much of this happens outside your network |
| Initial access | Tries the entry routes the scenario permits | Approves any change of route and answers deconfliction calls | Handle whatever they detect as they would a real event |
| Toward the objective | Moves carefully toward the goal, recording every action with a time | Watches for stop conditions | Detection and escalation under real conditions |
| Objective | Proves the goal was reached with the agreed evidence | Confirms the end of active work | Are told the exercise has ended |
| Reporting | Writes up the path and lines it up against your alert history | Shares tickets, alerts and response notes from the period | Learn what they missed, what they caught, and why |
The attack detail inside each phase depends on your scenario and is agreed with the white cell, so it is not published here.
Who is on the team. The size of the team is agreed in the written proposal.
How long it runs. A red team usually needs a longer window than a penetration test of the same estate, because an intruder who wants to stay unseen moves slowly. How long the exercise runs is written into the proposal.
Where we work from. Our only office is in Hyderabad. The digital parts of an exercise are run remotely from there, and anything that needs a person at your site is arranged separately.
06 / Report
What the report shows: the attack narrative and detection gaps
A red team report reads less like a list and more like a timeline. It tells the story of the route taken, then sets that story beside what your defenders saw and did.
Show details for What the report shows: the attack narrative and detection gaps
The heart of a red team report is the attack narrative: the route from the starting point to the objective, step by step, with the time of each action, the kind of weakness it relied on and the evidence that it worked. Beside that story sits a detection gap analysis, which asks of every step whether it was prevented, logged, alerted on, escalated and contained, and how long each of those took. Patterns in the gaps usually point to root causes in coverage, in alert tuning or in process, and those causes are what the recommendations address.
Illustrative A detection gap summary might look like this:
| Stage | What the red team did | What defenders saw | Gap to close |
|---|---|---|---|
| Initial access | Signed in to a staff account from an unfamiliar location | An alert, closed as a false positive | Triage guidance for unusual sign-ins |
| Foothold | Ran an unfamiliar program on one laptop | An endpoint alert that nobody escalated overnight | An out-of-hours escalation path |
| Movement | Reused one set of credentials across several servers | Nothing recorded | Server logging in that network segment |
| Objective | Copied the marker file from the finance share | Noticed later, in a routine review | An alert on access to that share |
- An executive report that answers the board's question in plain words: was the objective reached, how far did detection get, and what should change first.
- An engineering report for the individual weaknesses met on the way, each with a proof of concept and a fix, because a red team still trips over ordinary vulnerabilities.
- A remediation matrix that ranks those weaknesses and the detection gaps together, so engineering and the security operations team work from one list.
- Narrative and gap analysis: The report includes an attack narrative and a detection gap report.
Individual findings follow the same layout as every BERRY9 test; the sample VAPT report shows how a finding, its evidence and its fix are presented. Scoping, authorization and reporting follow the VAPT methodology.
A red team that is caught early has not failed. A quick, correct response is exactly what a defending team hopes to show, and the report records it with the same care as a miss.
07 / Purple team
Purple teaming: turning the exercise into better detection
Purple teaming is the variant where the defending side is told and takes part. Attackers and defenders work in the open, so every action becomes a chance to test and improve a detection.
Show details for Purple teaming: turning the exercise into better detection
Red team
Covert. Defenders are not told, so the result measures what really happens when an intruder arrives. It gives an honest answer to whether you would notice.
Purple team
Open. Attackers and defenders sit together, one action at a time, and fix detections on the spot. It builds coverage quickly when monitoring is young.
Debrief after a red team
The covert exercise is replayed with the defenders, step by step, beside their own logs. It turns one exercise's gaps into lasting detections.
In a purple team session the red side performs an action and the defenders check, in the moment, whether it was logged, whether it raised an alert and whether the alert would have reached a person. Where it did not, they change a rule or a log source and the action is run again until the detection works. Many teams describe these actions with MITRE ATT&CK, a public catalog of attacker behavior, so both sides use the same names and the results can be tracked over time.
Purple teaming suits three situations: right after a red team, to work through the gaps it found; in place of a red team, when monitoring is new and needs coverage more than a test; and when you change your security operations provider and want proof that the new one sees what the old one did.
A debrief workshop with your defenders. BERRY9 runs purple team sessions with your defenders, either as an open exercise or as a debrief after a red team.
08 / Price
What a red team exercise costs
A red team assessment starts from INR 27,000 + 18% GST; the final price is set in a written proposal after scoping. The starting figure applies to the smallest scope, and a covert exercise with several objectives is a larger piece of work, priced to match.
Red team assessment
Starts fromINR 27,000 + 18% GST
The final price is set in a written proposal after scoping, once objectives, routes and the window are agreed.
Request a scoping call- Objectives. One goal is a smaller exercise than three; each additional objective adds planning, work and reporting.
- Routes in scope. Digital routes alone, or people and premises as well, change both the effort and the preparation the rules of engagement need.
- Length of the window. Moving slowly enough to stay unnoticed takes time, and a longer window costs more.
- Covert or open. An open purple team session is planned differently from a covert exercise and is usually shorter.
- Size of the estate. Several offices, domains or cloud accounts give the red team more ground to cover and the white cell more to coordinate.
If one objective inside a penetration test is enough, it becomes part of that test's scope and proposal instead. How the price of this work compares with other tests is set out in the VAPT cost guide for India.
The starting price for small scopes includes one free retest. For larger scopes, the retest terms are written into the proposal before work starts.
Red team exercises by city
09 / Inquiry
Tell us what you want to find out
Tell us what testing you have had, how your alerts are monitored, which objective worries you most and whether people or premises should be in scope. With that, we can say whether a red team or a penetration test is the better use of the budget, and suggest a scope.
To talk it through first, call +91 86868 92922 or email contact@berry9.com.
10 / FAQ
Frequently asked questions
Short answers about scope, price and how testing works. For anything else, call +91 86868 92922.
What is the difference between red teaming and penetration testing?
A penetration test aims for coverage: testers work through a defined set of systems, usually in the open with your IT team, and hand back a ranked list of findings and fixes. A red team exercise aims for realism: it pursues one agreed objective, for example a particular database or administrative rights over Active Directory, along whatever routes the rules permit, and the defenders are not told. It measures whether your monitoring and response would catch a real intruder, not how many vulnerabilities exist. Most organizations need penetration tests first; a red team suits those that already have detection in place. See the section on Red teaming vs penetration testing above.
What are adversary simulation services?
Adversary simulation means running an exercise that behaves like a real attacker with a real goal, so that an organization can see how its defenses and its people respond. Red teaming is the most common form. The phrase adversary emulation is sometimes used for exercises that copy the known behavior of one particular threat group closely. In every form, the work is authorized in writing and bounded by rules of engagement.
How much does a red team exercise cost in India?
At BERRY9, a red team assessment starts from INR 27,000 + 18% GST; the final price is set in a written proposal after scoping. The main factors are the number of objectives, whether people and premises are in scope as well as systems, the length of the window and the size of the estate. A single objective added to a penetration test costs far less than a covert exercise with several scenarios. See the section on What a red team exercise costs above.
How long does a red team engagement take?
Usually longer than a penetration test of the same systems, because an intruder who wants to stay unseen has to move slowly and the defenders need time to notice, or not. Planning and the rules of engagement also take time before any activity starts. The window for a given exercise is agreed during scoping and written into the proposal.
What is a purple team exercise?
A purple team exercise brings the attacking side and the defending side together in the open. The red side performs an action, the defenders check whether it was logged and alerted on, and where it was not, they adjust and try again. It builds detection quickly, which makes it a good choice when monitoring is new or straight after a covert red team. See the section on Purple teaming: turning the exercise into better detection above.
Does our security team know about the red team exercise?
Only a small control group, often called the white cell, knows. It usually includes a senior security lead and an executive sponsor, who approve the scope, handle any surprises and can pause the exercise. The defenders are not told, because the point is to see how they respond to activity they believe could be real. The white cell can confirm quickly whether an alert belongs to the exercise, so a genuine incident is less likely to be dismissed as part of the exercise. See the section on Rules of engagement, the white cell and stop conditions above.
Do we need a penetration test before a red team?
In most cases, yes. A red team against systems that have never been tested tends to walk through well-known weaknesses and tells you little about detection. Penetration tests find and fix those weaknesses across the whole scope first; the red team then asks whether a determined intruder could still reach a goal, and whether anyone would notice. See the section on When you are ready for a red team, and when you are not above.
Can a red team exercise include phishing?
It can, provided the organization has given written approval for it and the agreed rules list the people who may be approached and the methods allowed. Phishing and other social engineering are then one possible route toward the objective, not a test of individual employees. Exercises that focus on how staff respond to deception can also be run on their own as a social engineering assessment. See the section on Objectives and scenarios, agreed before anything starts above.
Could a red team exercise disrupt our systems?
Any activity on live systems carries some risk, and the rules of engagement exist to manage it. Fragile systems can be excluded, actions that could cause harm can be ruled out, and stop conditions let the white cell pause or end the exercise at any time. The permitted actions and the hard limits are written down and signed before any activity begins. See the section on Rules of engagement, the white cell and stop conditions above.
Will the red team try to get past our endpoint protection and monitoring?
It will try to avoid being seen, as a real intruder would, because the exercise measures what your controls detect and stop. Nobody can honestly promise in advance to slip past a particular security product, and that is not the aim. A red team that is caught early has still shown you something valuable: that detection and response worked when it mattered.
Does a red team replace our annual penetration test?
No. The two answer different questions. A penetration test gives broad coverage of a defined scope and is what audits, customers and regular change cycles usually call for. A red team gives a realistic answer about one objective and about your ability to respond. Organizations that run red teams normally keep testing their applications and networks on their usual schedule as well.