Skip to content

fix: Update utils.go to fix the decoding process of the accessToken BED-7918#111

Open
yuunaka1 wants to merge 2 commits intoSpecterOps:mainfrom
yuunaka1:main
Open

fix: Update utils.go to fix the decoding process of the accessToken BED-7918#111
yuunaka1 wants to merge 2 commits intoSpecterOps:mainfrom
yuunaka1:main

Conversation

@yuunaka1
Copy link
Copy Markdown

@yuunaka1 yuunaka1 commented Feb 5, 2025

The accessToken (JWS Payload) uses Base64URL encoding, not Base64 encoding. Therefore, the base64.RawURLEncoding function should be used for the decoding.
ref: https://datatracker.ietf.org/doc/html/rfc7515#section-7.1

Summary by CodeRabbit

  • Bug Fixes
    • Fixed JWT token decoding to properly handle payloads with URL-safe character encodings.

The body (JWS Payload) uses Base64URL encoding, not Base64 encoding. Therefore, the base64.RawURLEncoding function must be used for the decoding.
@github-actions
Copy link
Copy Markdown

github-actions bot commented Feb 5, 2025

All contributors have signed the CLA ✍️ ✅
Posted by the CLA Assistant Lite bot.

@yuunaka1
Copy link
Copy Markdown
Author

yuunaka1 commented Feb 5, 2025

I have read the CLA Document and I hereby sign the CLA

@KinakoExE
Copy link
Copy Markdown

@mvlipka @ddlees
Hello, I encountered an AzureHound bug that throws the error:
illegal base64 data at input byte XXX.
This PR resolves the issue, so I would strongly recommend merging it.

Problem

Entra ID returns URL-safe base64-encoded JWTs. However, AzureHound attempts to decode them using the standard (non–URL-safe) base64 decoder. As a result, even valid access tokens can trigger a fatal error.

Here’s a real example I ran into:

$ ./azurehound list -t "$TENANT_ID" -j "$ACCESS_TOKEN" -o output.json -v 1
...
No configuration file located at /home/kali/.config/azurehound/config.json
2025-08-21T13:15:50+09:00 DBG testing connections
2025-08-21T13:15:50+09:00 DBG testing connections
2025-08-21T13:15:50+09:00 ERR encountered unrecoverable error error="failed to create new Azure client: illegal base64 data at input byte 634"

@Mike-Crowley
Copy link
Copy Markdown

Any chance this can get merged? This is a one-line fix that's been open for over a year.

Just hit this exact issue on v2.11.0 with a GCC tenant — see #160 and #186. The --jwt flag is completely broken for any tenant whose token payload contains base64url characters (- or _), which is common.

The workaround is to use app registration auth (-a/-s) instead, but that requires creating an app registration and granting permissions — a lot of unnecessary friction for what should be a simple az account get-access-token | azurehound --jwt workflow.

@StranDutton
Copy link
Copy Markdown
Contributor

StranDutton commented Apr 7, 2026

@Mike-Crowley Hello! Thank you for the reminder, I'll get this triaged soon 👍

@coderabbitai
Copy link
Copy Markdown

coderabbitai bot commented Apr 9, 2026

Walkthrough

The ParseBody function in the JWT parsing utility now uses Base64URL decoding instead of standard Base64 decoding when processing JWT payload segments, aligning with JWT specification requirements for URL-safe character handling.

Changes

Cohort / File(s) Summary
JWT Payload Decoding
client/rest/utils.go
Changed Base64 decoding method from base64.RawStdEncoding to base64.RawURLEncoding in the ParseBody function to properly decode JWT payload segments according to JWT specification standards.

Possibly Related Issues

Estimated Code Review Effort

🎯 2 (Simple) | ⏱️ ~12 minutes

Poem

🐰 A hop, a skip, a URL so safe,
Base64 encoding in proper shape,
JWT tokens now decode just right,
With dashes and underscores, oh what a sight!

🚥 Pre-merge checks | ✅ 2 | ❌ 1

❌ Failed checks (1 warning)

Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. Write docstrings for the functions missing them to satisfy the coverage threshold.
✅ Passed checks (2 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title accurately describes the main change: fixing the decoding process of the accessToken by updating utils.go to use proper Base64URL encoding instead of standard Base64.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

@rvazarkar rvazarkar changed the title Update utils.go to fix the decoding process of the accessToken fix: Update utils.go to fix the decoding process of the accessToken BED-7918 Apr 9, 2026
@rvazarkar
Copy link
Copy Markdown
Contributor

https://specterops.atlassian.net/browse/BED-7918

For internal tracking

@rvazarkar rvazarkar added the bug Something isn't working label Apr 9, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Something isn't working ticketed

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants