During a penetration test of a server application, a security consultant found that the application randomly crashed or remained stable after opening several simultaneous connections to the…

Question

Options

• AAttach a remote profiler to the server application. Establish a random number of connections to
• BAttach a remote debugger to the server application. Establish a large number of connections to
• CAttach a local disassembler to the server application. Establish a single connection to the server
• DAttach a remote disassembler to the server application. Establish a small number of connections

• A
  14% (5)
• B
  74% (26)
• C
  3% (1)
• D
  9% (3)

Explanation

The scenario describes a race condition or resource exhaustion vulnerability triggered by concurrent connections - a dynamic runtime issue. A remote debugger (B) is the correct tool because it attaches to the live running process and captures runtime state (memory, registers, stack traces) at the moment of a crash, enabling the tester to identify the root cause and develop an exploit. A profiler (A) measures performance metrics (CPU, memory usage) rather than crash state. A local disassembler (C) performs static analysis of binary code and cannot observe dynamic runtime behavior across multiple concurrent sessions. A remote disassembler (D) has the same limitation as a local one - static analysis cannot capture the timing-sensitive crash behavior. The 'large number of connections' is also critical because the crash was random with simultaneous connections, so volume is needed to reliably reproduce it.

No community discussion yet for this question.