Testing ServicesУслуги тестирования

Black-Box Testing

Black-box engagements start with zero knowledge — only a domain name, exactly as an external attacker would have. The tester enumerates your public footprint, discovers exposed services, fingerprints technologies, and exploits what they find, without credentials, architecture docs, or source code. Black-box проекты начинаются без знаний — только доменное имя, как у внешнего атакующего. Тестировщик перечисляет публичный периметр, обнаруживает открытые сервисы, определяет технологии и эксплуатирует найденное — без учётных данных, документации по архитектуре или исходного кода.

Methodology follows OWASP, PTES, and MITRE ATT&CK. Every finding is manually verified — only confirmed vulnerabilities with proven impact reach the report. Critical findings are reported within a 48-hour SLA, not held back until the final report. A typical engagement runs 5–14 days and includes a 30-day free retest. Методология по OWASP, PTES и MITRE ATT&CK. Каждая находка проверяется вручную — в отчёт попадают только подтверждённые уязвимости с доказанным влиянием. Критические находки сообщаются в рамках 48-часового SLA, не дожидаясь финального отчёта. Обычно проект занимает 5–14 дней и включает бесплатный 30-дневный ретест.

White-Box Testing

White-box testing gives the tester full source code and architecture access. This surfaces roughly twice the findings of a black-box engagement, since logic flaws, broken access control, and issues hidden behind authentication are visible from day one instead of requiring hours of blind probing. White-box тестирование даёт тестировщику полный доступ к коду и архитектуре. Это выявляет примерно вдвое больше находок, чем black-box, поскольку логические ошибки, нарушения контроля доступа и проблемы за аутентификацией видны с первого дня, а не требуют часов слепого прощупывания.

Coverage includes STRIDE threat modelling of trust boundaries and privilege models, static analysis (SAST) with every automated finding manually triaged, dynamic testing with full application credentials, and a dependency/supply-chain audit — CVE sweep, container images, git history secrets, and CI/CD configuration. Покрытие включает STRIDE-моделирование угроз для границ доверия и моделей привилегий, статический анализ (SAST) с ручной триажировкой каждой автоматической находки, динамическое тестирование с полными учётными данными приложения и аудит зависимостей/supply chain — проверку CVE, образов контейнеров, секретов в истории git и конфигурации CI/CD.

The report includes file- and line-level references with fix snippets in your language, so developers start fixing immediately instead of reverse-engineering a vague vulnerability category. Отчёт содержит ссылки на файл и строку с примерами исправлений на вашем языке программирования — разработчики начинают исправлять сразу, без реверс-инжиниринга расплывчатой категории уязвимости.

Grey-Box Testing

Grey-box sits between the two: the tester receives scoped knowledge transfer — API docs, an architecture overview, and role-based credentials — but no source code. This removes the time normally spent on blind reconnaissance while keeping an outside perspective on the parts of the system that weren't documented. Grey-box находится между двумя подходами: тестировщик получает ограниченный объём знаний — API-документацию, обзор архитектуры и ролевые учётные данные — но не исходный код. Это убирает время, обычно уходящее на слепую разведку, сохраняя взгляд со стороны на недокументированные части системы.

Testing covers authenticated access across every provided user role — privilege escalation, IDOR, broken authorization — plus full API and business-logic testing (injection, auth bypass, parameter manipulation, rate-limit failures) and an optional insider-threat scenario simulating a disgruntled employee or phished credential. Тестирование охватывает аутентифицированный доступ по каждой предоставленной роли — эскалация привилегий, IDOR, нарушения авторизации — а также полное тестирование API и бизнес-логики (инъекции, обход аутентификации, манипуляция параметрами, отказы rate-limit) и опциональную симуляцию инсайдерской угрозы — недовольного сотрудника или фишинговых учётных данных.

Grey-box typically surfaces 1.6× the findings of black-box at a fraction of the cost and time of a full white-box review — a good default when you want more than an outside-in view but can't share source code. Grey-box обычно выявляет в 1,6 раза больше находок, чем black-box, при доле стоимости и времени полного white-box ревью — хороший вариант по умолчанию, когда нужно больше, чем взгляд снаружи, но код передать нельзя.

Mobile TestingТест мобильных приложений

Mobile applications carry an attack surface that desktop and web pentests don't cover: insecure on-device storage, runtime manipulation via Frida, hardcoded credentials in binaries, weak certificate pinning, and backend APIs that trust client-side data. Coverage spans native iOS and Android, hybrid (React Native, Flutter, Xamarin), and mobile web wrappers. Мобильные приложения имеют поверхность атаки, которую не покрывают десктопные и веб-пентесты: небезопасное хранение данных на устройстве, рантайм-манипуляции через Frida, захардкоженные учётные данные в бинарниках, слабый certificate pinning и backend API, доверяющие клиентским данным. Покрытие охватывает нативные iOS и Android, гибридные (React Native, Flutter, Xamarin) и мобильные веб-обёртки.

Testing combines static analysis of decompiled binaries with dynamic testing on real instrumented devices, and always includes the backend API the app calls — findings are mapped to the OWASP Mobile Application Security Verification Standard (MASVS). Тестирование сочетает статический анализ декомпилированных бинарников с динамическим тестированием на реальных инструментированных устройствах и всегда включает backend API, который вызывает приложение — находки маппируются на стандарт OWASP MASVS.

Cloud TestingОблачная безопасность

Cloud engagements review infrastructure and configuration across AWS, GCP, and Azure — IAM policies, network segmentation, storage bucket permissions, and infrastructure-as-code templates (Terraform, CloudFormation, Pulumi, Bicep) are checked alongside the live environment, since a misconfigured template is the root cause of most cloud incidents. Облачные проекты проверяют инфраструктуру и конфигурацию в AWS, GCP и Azure — IAM-политики, сегментацию сети, права доступа к хранилищам и шаблоны инфраструктуры как кода (Terraform, CloudFormation, Pulumi, Bicep) проверяются вместе с реальной средой, поскольку неверный шаблон — первопричина большинства облачных инцидентов.

Testing is read-only by default — Nullify operates with view-only access, eliminating any risk of accidental change or deletion of resources. A minimal-privilege policy document is provided so access can be granted and revoked in minutes. По умолчанию тестирование проводится только на чтение — Nullify работает с правами только на просмотр, что исключает риск случайного изменения или удаления ресурсов. Предоставляется документ с минимальной политикой прав, позволяющий выдать и отозвать доступ за минуты.

Reverse EngineeringРеверс инжиниринг

Binary and firmware analysis uncovers hidden vulnerabilities and logic flaws that don't surface through black-box testing alone — hardcoded secrets, insecure update mechanisms, and undocumented functionality embedded in compiled code. Анализ бинарников и прошивок выявляет скрытые уязвимости и логические ошибки, которые не проявляются при обычном black-box тестировании — захардкоженные секреты, небезопасные механизмы обновления и недокументированную функциональность, встроенную в скомпилированный код.

Red Team OperationsRed Team операции

A red team engagement is objective-driven, not vulnerability-driven: operators attempt to reach a specific goal — steal data, achieve persistence, compromise an executive's email — using stealth over weeks, combining network intrusion, phishing, social engineering, and physical access attempts the way a real adversary would. Red Team проект ориентирован на цель, а не на поиск уязвимостей: операторы пытаются достичь конкретной задачи — украсть данные, закрепиться, скомпрометировать почту руководителя — скрытно на протяжении недель, комбинируя сетевое проникновение, фишинг, социальную инженерию и попытки физического доступа так же, как это делает реальный атакующий.

Four roles participate: Red Team (the attackers), Blue Team (your SOC, which detects and responds without prior warning), Purple Team (joint sessions that turn findings into permanent detections), and White Team (your arbiter, who coordinates the engagement and makes the call on critical decisions). В проекте участвуют четыре роли: Red Team (атакующие), Blue Team (ваш SOC, который обнаруживает и реагирует без предупреждения), Purple Team (совместные сессии, превращающие находки в постоянные детекты) и White Team (ваш арбитр, координирующий проект и принимающий решения по критическим вопросам).

A typical engagement runs 6–10 weeks: 1–2 weeks of intelligence-driven planning, 4–6 weeks of active multi-vector execution, and 1–2 weeks of reporting with separate executive and technical debriefs. The final report reconstructs the full attack chain mapped to MITRE ATT&CK. Типичный проект занимает 6–10 недель: 1–2 недели планирования на основе разведки, 4–6 недель активного многовекторного выполнения и 1–2 недели отчётности с отдельными сессиями разбора для руководства и инженеров. Финальный отчёт восстанавливает полную цепочку атаки с маппингом на MITRE ATT&CK.