5.1 Encoding, Encryption, Hashing, and Decoding Tools

Security Operations Center (SOC) analysts are not asked to invent new ciphers. They are asked to look at a string in an alert and decide what it is. A Base64 command, a TLS (Transport Layer Security) session, and a SHA-256 file hash can all look like unreadable junk at a glance. Treating them as the same thing produces the wrong action: you might try to decrypt a hash, assume Base64 is secret, or ignore a password dump because it is hashed. This independent study section covers encoding, encryption, hashing, and decoding workflows that appear in Security Analyst Level 1 (SAL1) cryptography topics.

Why cryptography basics belong in triage

Process-creation logs, proxy URLs, email headers, and threat-intel tickets constantly carry transformed data. Your first job is classification.

• If the bytes are encoding, reverse the scheme and continue the investigation on the recovered script, URL, or credential-shaped text.
• If the bytes are encryption, you need a key, a TLS intercept point, or host telemetry from before encryption or after decryption. You cannot decode ciphertext with a public alphabet.
• If the bytes are a hash, compare them to another digest or a known-file catalog. You cannot recover the original file from the hash.

Those three outcomes lead to three different case-note sentences. Mixing them up wastes investigation time and produces misleading indicators of compromise (IoCs).

Encoding versus encryption versus hashing

Encoding changes how data is represented so systems can carry it. There is no key. Anyone who knows the scheme reverses it. Encoding is a convenience, not a confidentiality control.

Encryption uses an algorithm plus a key so that plaintext becomes ciphertext. Reversing the process (decryption) requires the correct key, or a failure in the cryptosystem. Encryption's primary security job is confidentiality.

Hashing runs a one-way function and emits a fixed-length digest. You verify integrity by hashing again and comparing. You do not decrypt a hash. Hashing is not a way to keep the original secret unless you add a slow password-hashing design, a unique salt, and related controls — and even then the digest is for verification, not for reading the password back.

Encodings you must recognize on sight

Base64 uses uppercase letters, lowercase letters, digits, +, /, and = padding. Padded Base64 strings have length divisible by four. Attackers embed Base64 in PowerShell -enc arguments because the alphabet passes through logs that might block the word Invoke-Expression. Base64 does not stop an analyst who decodes it.

Hexadecimal (hex) writes each byte as two characters from 0-9 and a-f. The hex string 48656c6c6f is the ASCII word Hello. Packet captures, memory notes, and some configuration blobs use hex.

URL encoding (percent-encoding) replaces reserved characters with % and two hex digits. admin%40corp.local is admin@corp.local. Web logs and phishing URLs are full of this form.

A useful trap: people call any unreadable string encrypted. Unreadable plus a public mapping is encoding. Unreadable plus a key is encryption. Unreadable plus fixed-length hex is often a hash.

Symmetric encryption, asymmetric encryption, and TLS

Symmetric encryption uses one shared secret for both directions. AES (Advanced Encryption Standard) is the bulk cipher you will hear in disk encryption and in many TLS ciphersuites. Symmetric algorithms are efficient, which is why they protect large streams. The hard part is distributing the shared key without exposing it.

Asymmetric encryption uses a public key and a private key. Anyone may encrypt to the public key or verify a signature; only the private-key holder decrypts or signs. RSA (Rivest–Shamir–Adleman) and elliptic-curve algorithms show up in certificates. Asymmetric operations are expensive, so protocols rarely encrypt whole files with RSA alone.

Production protocols combine both families. TLS is the example that matters for analysts. During the handshake, public-key cryptography authenticates the server (and sometimes the client) and agrees on fresh symmetric keys. After that, AES-class ciphers protect the HTTP bytes in transit.

Remember what TLS does not do:

• It does not encrypt the web server's database at rest.
• It does not encrypt a PowerShell script sitting in a Windows process-creation command line.
• It does not turn Base64 into a secret.
• A URL that starts with https:// means the path to the site was wrapped in TLS, not that a dropped executable is encrypted on disk.

If you need the plaintext of an HTTPS session, look for host-based evidence (browser, script interpreter, decoded command line) or an authorized TLS inspection proxy. Forcing a Base64 alphabet onto TLS records will not unwrap the session.

In practice: an alert with HTTPS and a Base64 field

A proxy alert shows https://files.example.com/update plus a query parameter d=cGFzc3dvcmQ=. TLS protected the network path. After you decode the parameter with Base64, you get the ASCII string password. You now have a credential-shaped string that was only encoded in the query. Your notes should record both facts: transport used TLS; the parameter was Base64 encoding, not encryption.

Worked example: a Base64 blob that looks like a password versus a SHA-256 hex digest

Suppose an alert field contains:

cGFzc3dvcmQ=

A recipe-style decode — any tool that implements standard Base64, not a required branded product — yields password. That is encoding. The original value might be a password, a token, or junk, but Base64 did not protect it. If you treated this as encrypted, you would stop at the wrong conclusion and might never search for reuse of that password.

Now suppose the field contains:

5e884898da28047151d0e56f8dc6292773603d0d6aabbdd62a11ef721d1542d8

Count the characters: 64 hexadecimal characters. That is 32 bytes, which is the output length of SHA-256 (Secure Hash Algorithm 256-bit). You cannot decode it back to a password the way you reversed Base64. You can only compare it to another SHA-256 digest or look it up in a hash catalog. This particular digest is a well-known SHA-256 of the word password, which is exactly why unsalted, fast hashes fail as password storage.

Use this sight-recognition checklist:

• Printable alphabet with = padding and length divisible by 4 → try Base64 first.
• Only 0-9a-f, length 32 → often MD5 (Message Digest 5), 128 bits.
• Only 0-9a-f, length 40 → often SHA-1, 160 bits.
• Only 0-9a-f, length 64 → often SHA-256, 256 bits.
• Structured TLS records or random binary → not a hash you paste into a Base64 decoder.

Hashing for integrity, not confidentiality

Hashing answers: is this the same byte sequence I saw before? It does not answer: can an attacker read this?

MD5 produces a 128-bit digest (32 hex characters). It is broken for collision resistance and is too fast for password storage. You will still see MD5 in older tools and some malware catalogs; treat it as a weak identifier, not a modern integrity standard.

SHA-1 produces 160 bits (40 hex characters). Collision attacks are practical in research settings. Do not choose SHA-1 for new integrity designs. You may still match SHA-1 values in legacy ticket fields.

SHA-256 produces 256 bits (64 hex characters) and is the common file-hash field in modern threat-intel and endpoint-detection consoles. Matching a SHA-256 to a known-bad catalog is an integrity and identification step. It does not mean the file was confidential while it sat on disk.

Why unsalted MD5 is weak for passwords

Password hashing is a special case. If you store MD5(password) with no salt (a per-user random value mixed into the input):

1. Two users with the same password get the same hash, which leaks password reuse inside the database.
2. Attackers precompute tables for common passwords because MD5 is fast and the input space of common passwords is small.
3. The well-known MD5 of password is 5f4dcc3b5aa765d61d8327deb882cf99. Looking that value up is trivial.

Modern password storage uses a slow, memory-hard function such as bcrypt, scrypt, or Argon2, plus a unique salt. As an analyst, if you find a dump of 32-character hex values and no salts, treat it as high-risk credential exposure even before anyone recovers a single plaintext password.

Decoding tools in an analyst workflow

You do not need a branded decoder as official exam software. You do need a decode-recipe habit, the same idea popularized by kitchen-style transform pipelines:

1. Identify the likely scheme (Base64, hex, URL encoding, then maybe compression or a second Base64 layer).
2. Apply one transform at a time.
3. Stop when you have readable text, a script, a URL, or a binary you can hash — not when you merely have another blob.
4. Never assume a decode equals a decrypt. If a key was required and you do not have it, you are not looking at encoding.

Layered encoding is common: URL-encode a Base64 string, or Base64-encode a script that itself contains hex. Work from the outside in. Record each step in the case notes so another analyst can reproduce the result.

If a string still looks random after standard encodings, consider encryption, compression, or a custom alphabet. Do not force a Base64 decode on a SHA-256 hex string; you will get garbage and waste triage time.