🕓 Page: Editing Previous Passwords Attack#
This view represents a specialized dictionary-style attack that uses a dynamic wordlist composed of previously cracked passwords from the same project/campaign. It allows rule-based modifications ("modificators") such as case conversion or character substitutions.
💡 Summary#
- UI built as a modal dialog with standard styling
- No manual wordlist upload — dictionary is automatically linked to dynamic wordlist (
AttackResourceType.DYNAMIC_WORD_LIST) - Shows live-updating complexity and estimated keyspace (
Passwords to check) - Modifier rules apply dynamically to the pre-collected password set
- Backend must treat this as a subclass of dictionary attack but link it to a dynamic source
🧾 Header#
<h3 class="text-xl font-bold text-gray-900 dark:text-white">
Editing Previous Passwords Attack
</h3>
<p class="text-sm text-gray-500 dark:text-gray-400">
Previous Passwords Attack checks passwords that were previously recovered by
other attacks for other files.
</p>
🛠️ Modificators Block#
🔹 Input Wordlist (Dynamic)#
This field is static text. The actual wordlist is system-generated and not editable.
<p class="text-sm text-gray-500 dark:text-gray-400 mb-1">
Input: dictionary password
</p>
🔁 Active Modifier (Change Case Example)#
Once + Change case is clicked, a visible rule tag appears beneath the input label:
<div class="mb-2 text-sm text-blue-600 dark:text-blue-400">
Case: original, normal, upper, lower
</div>
- original: unmodified
- normal: title case
- upper: all uppercase
- lower: all lowercase
- These should map to a preconfigured rule file or be translated server-side into rule syntax.
➕ Modifier Buttons#
<div class="flex flex-wrap gap-2 mb-4">
<button class="btn btn-link" type="button">
+ Change case
</button>
<button class="btn btn-link" type="button">
+ Change chars order
</button>
<button class="btn btn-link" type="button">
+ Substitute chars
</button>
</div>
Each button opens a modifier configuration area (or toggles a preset), shown inline as preview tags or configuration badges. The implementation should handle this as UI-to-rule mapping logic and set the appropriate rule_list_id internally.
📤 Output Section#
This is a visual placeholder — no actual field is shown in the mockup:
<p class="text-sm text-gray-500 dark:text-gray-400">
Output
</p>
Can be omitted unless you plan to show a visual preview of generated candidates later.
📊 Estimation Block#
<div class="mt-4 text-sm text-gray-900 dark:text-white">
<p>
<strong>
Passwords to check:
</strong>
140
</p>
<p>
<strong>
Complexity:
</strong>
<span class="inline-flex space-x-1">
<span class="w-2 h-2 bg-gray-400 rounded-full">
</span>
<span class="w-2 h-2 bg-gray-400 rounded-full">
</span>
<span class="w-2 h-2 bg-gray-400 rounded-full">
</span>
<span class="w-2 h-2 bg-gray-400 rounded-full">
</span>
<span class="w-2 h-2 bg-gray-400 rounded-full">
</span>
</span>
</p>
</div>
Estimation is likely based on:
- Number of cracked passwords
- Rule permutations added
- Any applied filtering patterns
The implementation should call: POST /api/v1/web/attacks/estimate
whenever modifiers are toggled.
✅ Footer Controls#
<div class="flex justify-end space-x-2 mt-6">
<button class="btn btn-outline" type="button">
Cancel
</button>
<button class="btn btn-primary" type="submit">
Save Attack
</button>
</div>
📦 Backend Submission Payload#
{
"attack_mode": "dictionary",
"attack_mode_hashcat": 0,
"word_list_id": "<autogenerated-dynamic-id>", // linked to internal dynamic wordlist
"rule_list_id": "<optional>", // based on selected modifiers
"is_dynamic_source": true // optional flag to help backend logic
}
🔒 Notes for Skirmish#
- Wordlist is read-only and tied to prior crack results for the current campaign/project
- Case modifier options should map to a known rule file or inlined rule syntax
- If a user clicks multiple modifier buttons, rules should be composed logically (or reject invalid combinations)
- Live preview of estimated password count is helpful but not required
