Logging and Verbosity

Logging & Verbosity

GCPwn has three independent knobs that control what you see and what gets recorded:

1. Verbosity — the per-run -v / --debug flag (adds [DEBUG] lines).
2. Output format — the std_output_format config (text vs table).
3. On-disk records — an automatic run-history log, plus greppable [DOWNLOAD] lines for content pulls.

They are orthogonal: you can run quiet-but-tabular, or verbose-but-plain, in any combination.

Table of Contents

• Verbosity: -v / --debug
• Output format: text vs table
• Console line prefixes
• On-disk run history
• Download audit records
• Errors and tracebacks

Verbosity: -v / --debug

Verbosity is a per-run flag, not a saved config — add -v (or --debug, they are the same flag) to any modules run ... invocation. It turns on [DEBUG] lines that show per-call detail: the API being called, the arguments/URLs (sanitized), page counts, and so on. Without it you get the normal info/warning/error stream only.

# quiet (default): info/warnings/errors + the end-of-run summary
modules run enum_cloudstorage --buckets

# verbose: the same, plus [DEBUG] lines for each API call / decision point
modules run enum_cloudstorage --buckets -v

What the extra [DEBUG] lines look like (fake data):

[DEBUG] Listing buckets for project :: project_id='prod-project-123'
[DEBUG] storage.buckets.list returned :: count=42 page_token=None
[DEBUG] testIamPermissions on bucket :: bucket='acme-backups' permissions=['storage.objects.get', 'storage.objects.list']
[*] prod-project-123: 42 bucket(s), 3 externally/publicly exposed

-v is forwarded automatically to sub-modules — e.g. enum_all -v runs every service enumerator (and the trailing Google Workspace phase) in verbose mode.

Output format: text vs table

Separate from verbosity, std_output_format controls how result tables render. It is a saved workspace config (persists across runs), set from the REPL:

configs set std_output_format table   # render results as ASCII tables
configs set std_output_format text    # plain line output (DEFAULT)
configs list                          # see the current value
configs unset std_output_format       # back to the default (text)

• text (default) — one resource per line/block; grep-friendly, needs no extra dependency.
• table — aligned ASCII tables (via prettytable); easier to scan. Needs the optional extra: pip install "gcpwn[table]" (or pip install prettytable from a git clone). If it is not installed, GCPwn falls back to text.

text (default) — a Columns: / Rows: header, then each row as an - item N block:

Columns: name | location | public | storage_class
Rows: showing 2 of 2

- item 1
    name: acme-backups
    location: US
    public: yes
    storage_class: STANDARD

- item 2
    name: acme-logs
    location: EU
    public: no
    storage_class: NEARLINE

table (after configs set std_output_format table) — a bordered ASCII table with capitalized headers:

+--------------+----------+--------+---------------+
|     Name     | Location | Public | Storage_class |
+--------------+----------+--------+---------------+
| acme-backups |    US    |  yes   |    STANDARD   |
|  acme-logs   |    EU    |   no   |    NEARLINE   |
+--------------+----------+--------+---------------+

Console line prefixes

Live output is prefix-tagged so it is easy to skim or grep:

Prefix	Meaning
[*]	Info / progress summary
[!]	Warning (non-fatal — e.g. a download-time budget hit, a skipped region)
[X]	Error / failure
[***]	In-line progress counter (e.g. blobs processed)
[DEBUG]	Verbose detail — only with -v / --debug
[START_MODULE] / [END_MODULE]	Module run boundaries (also written to the history log)
[DOWNLOAD]	One line per file pulled to disk

Grep examples:

modules run enum_all --iam 2>&1 | tee run.txt
grep '^\[X\]' run.txt      # just the failures
grep '^\[!\]' run.txt      # just the warnings

On-disk run history

Every module run is appended, automatically and timestamped, to a per-workspace log:

gcpwn_output/<workspace>/tool_logs/history_log.txt

Each run writes a [START_MODULE] / [END_MODULE] boundary (with the project id when the module is per-project), so you can reconstruct exactly what you ran and when:

[2026-01-02 14:31:02] [START_MODULE] Entering enum_iam module for prod-project-123...
[2026-01-02 14:31:07] [END_MODULE] Exiting enum_iam module for prod-project-123...
[2026-01-02 14:31:07] [START_MODULE] Entering enum_cloudstorage module for prod-project-123...
[2026-01-02 14:31:44] [END_MODULE] Exiting enum_cloudstorage module for prod-project-123...

This is GCPwn's own activity trail — useful for reporting ("here is every action the assessment took") and for correlating against the target's Cloud Audit Logs.

Download audit records

Every file pulled to disk (Cloud Storage blobs, Drive files, secrets, serial output, ...) emits a single greppable [DOWNLOAD] line, so you can enumerate exactly what left the target:

[DOWNLOAD] downloader=user@CLIENT_DOMAIN file='q3-financials.xlsx' id=1AbC...xyz exposure=anyone_with_link owner=owner@CLIENT_DOMAIN bytes=48213 -> gcpwn_output/PROD/downloads/drive/user@CLIENT_DOMAIN/q3-financials.xlsx

--throttle <seconds> (on the download modules, e.g. enum_drive) sleeps between pulls so the pattern is deliberately observable — handy in a lab to generate detections in the target's Drive/Cloud audit logs and study them:

modules run enum_drive --all-users --download --throttle 2 | grep '^\[DOWNLOAD\]'

See Downloads to Disk for the full download flag set (including --download-timeout, the per-service/per-bucket wall-clock cap).

Errors and tracebacks

If a module raises, GCPwn prints the full Python traceback (regardless of -v) and continues with the next project/module rather than aborting the whole run — so one service failing never kills a broad enum_all; the per-project failure is collected and reflected in the run's overall exit. For expected API conditions (403 denied, API disabled, 404 not found), GCPwn prints a concise one-line reason instead of a traceback via the shared error handler, so a wall of 403s does not bury the real signal.