The one idea that fixes most of the confusion

Every forwarding setup has three roles:

• Listener: the socket that receives the initial connection. Something connects to it.

• Forwarder: the process that takes what hits the listener and pushes it somewhere else.

• Destination: the final service you actually want to talk to (a database, RDP, SMB, etc.).

The trap is assuming the listener is always on your local machine, or always on the target. This isn’t the case. In SSH tunnelling specifically, the SSH client and SSH server roles are about who initiated the SSH connection, and that is independent of which of them ends up hosting the listening port. Local vs. remote forwarding is entirely about that pairing. Once you interrogate “who is the SSH client here, who is the SSH server, and which one is listening,” the rest is just filling in IP: port pairs correctly.

Scenario setup

Assume a foothold on a compromised app server we’ll call JUMPBOX01 (192.168.60.50), sitting between our Kali machine (192.168.120.5) and a database host on an internal segment, DBHOST02 (10.10.20.30), which is only reachable from JUMPBOX01.

1. Socat — dumbest, fastest port forward

No SSH involved - relays TCP. Run this on the intermediary host (JUMPBOX01):

socat -ddd TCP-LISTEN:2345,fork TCP:10.10.20.30:5432

• Listener: port 2345 on JUMPBOX01.

• Forwarder: socat itself.

• Destination: port 5432 (Postgres) on DBHOST02.

From Kali, connect to JUMPBOX01’s IP on the listening port, and it’s transparently pushed to DBHOST02:

psql -h 192.168.60.50 -p 2345 -U postgres

Good for a quick, disposable relay but is weak on stealth. An odd listening port is easy to spot with basic monitoring, so it’s more suited to noisy, time-boxed lab work than an actual engagement.

2. SSH Local Port Forwarding (-L)

Mental model: “I (the SSH client) want to open my door that tunnels to something the SSH server can reach.”

Syntax:

ssh -N -L [LISTEN_IP:]LISTEN_PORT:DEST_IP:DEST_PORT user@SSH_SERVER

• The listener binds on the SSH client machine.

• Traffic goes: client listener → tunnel → SSH server → destination.

Say we’re SSH’d from JUMPBOX01 out to DBHOST02 (DBHOST02 is the SSH server here), and we’ve found a third host, FILESRV03 (172.20.10.40), reachable only from DBHOST02 with SMB open on 445:

ssh -N -L 0.0.0.0:4455:172.20.10.40:445 svc_admin@10.10.20.30

The way I like to think of this is: “from 0.0.0.0:4455, via svc_admin@10.10.20.30, to 172.20.10.40:445”.

From Kali, connect to JUMPBOX01’s IP on the listener port, and the traffic will be tunnelled through to DBHOST02 and pushed to FILESRV03 on port 445:

smbclient //192.168.60.50/share -p 4455

When to use it: you know exactly one destination socket you want to reach, and you’re fine opening just that one door.

3. SSH Dynamic Port Forwarding (-D) - the SOCKS proxy

Mental model: Same direction as local forwarding (client listens, server routes), but instead of hardcoding one destination, you get a full SOCKS proxy. Anything the SSH server can route to, you can now reach.

ssh -N -D 0.0.0.0:9999 svc_admin@10.10.20.30

Point proxychains at it (/etc/proxychains4.conf):

[ProxyList]
socks5 192.168.60.50 9999

Then run any tool through the tunnel, and traffic will be routed as addressed.

proxychains nmap -sT --top-ports=20 -Pn -n 172.20.10.40

Drop the tcp_read_time_out / tcp_connect_time_out values in proxychains’ config if scans feel painfully slow; the defaults are tuned for Tor, not internal pivoting.

When to use it: you don’t know the full target list yet, or you need to reach several hosts/ports beyond the pivot without opening a new forward for each one.

4. SSH Remote Port Forwarding (-R)

Mental model: This flips the listener to the other side. “I am the SSH client, but I want the SSH server to open the door, and I (the client) will do the forwarding back to something only I can reach.”

This is the pivot equivalent of a reverse shell and is useful when the compromised host can reach out, but nothing can reach in.

ssh -N -R [BIND_IP:]LISTEN_PORT:DEST_IP:DEST_PORT user@SSH_SERVER_YOU_CONTROL

Say your foothold is on JUMPBOX01, and JUMPBOX01 can dial out to your Kali box (192.168.120.5), which is running sshd. From JUMPBOX01 (acting as SSH client here):

ssh -N -R 127.0.0.1:2345:10.10.20.30:5432 kali@192.168.120.5

• Listener: port 2345, bound on Kali (the SSH server in this exchange) — loopback.

• Forwarder: the SSH client software running on JUMPBOX01.

• Destination: DBHOST02:5432, reachable from JUMPBOX01.

The part that sometimes trips me up is even though you set this up from JUMPBOX01, the port you actually connect to afterwards is on your own Kali box, not JUMPBOX01. The whole point of “remote” forwarding is the listener lives remotely, relative to where you typed the command.

5. SSH Remote Dynamic Port Forwarding

Same flip as above, but SOCKS-flavoured instead of one fixed destination. Only needs one thing: the port to bind on the SSH server:

ssh -N -R 9998 kali@192.168.120.5

Update /etc/proxychains4.conf:

socks5 127.0.0.1 9998

Now, from Kali, proxychains nmap or any other tool can reach anything JUMPBOX01 can route to without needing to know the destinations in advance:

proxychains nmap -vvv -sT --top-ports=20 -Pn -n 10.10.20.30

When to use it: You’re pivoting deeper through a host that can only reach you outbound, and you don’t yet know the full internal target list.

The fastest way to stop second-guessing syntax mid-engagement: before typing anything, say out loud “the listener is on ___, and it forwards to ___.” If you can’t fill in both blanks confidently, you’re not ready to type the command yet.

When using DH for agreeing on encryption session keys, a modulus of at least 2048 bits is used, preferably 3072 bits.

The evidence I’d been handed was a screenshot of a server’s TLS certificate, showing a 2048-bit RSA public key, similar to the one below:

At first glance it might look right, but it wasn’t evidence for ISM-0472 at all. Both things involve the word “modulus” and the number 2048, which is why this mix-up is so easy to make until you’ve sat down and pulled the two apart. So let’s pull them apart.

Two different jobs, two different keys

A TLS handshake actually needs to do two separate jobs:

1. Prove identity. The server needs to convince you it really is who it says it is. This is what the TLS certificate, like the screenshot above, is for. It contains a public key (often RSA, sometimes EC) that the server uses to sign parts of the handshake, proving it holds the matching private key.

2. Agree on a session key. Separately, the client and server need to agree on a fresh secret to encrypt the actual traffic for the session. If they’re using Diffie-Hellman (DH) to do this, that process involves its own key material, also known as a “temp key” or ephemeral key. Crucially, this has nothing to do with the certificate.

These are two different keys, generated for two different purposes. Importantly, there is no relationship between their sizes. A server can hand you a 4096-bit certificate for authentication and still negotiate a 1024-bit DH group for the session key.

That mismatch is, in fact, close to the basis of a real vulnerability class (Logjam, 2015), where servers supporting legacy export-grade DHE ciphers could be forced down to a 512-bit DH group, and where widespread reuse of the same standard primes meant one precomputation could compromise many servers at once. A strong certificate never told you any of that.

So the screenshot showed the RSA modulus of the certificate’s public key. Good evidence of authentication strength, but ISM-0472 is asking about the modulus used to derive the session key. In other words, the key used to encrypt the session traffic between the server and the client. Same word, same number, completely different thing. The evidence didn’t touch the control it was meant to support.

What “modulus” actually refers to in each case

It’s worth being precise here about what the term “modulus” actually means.

• Certificate / RSA modulus: this is the large number n that forms part of an RSA public key (n = p × q, two large primes). Its bit-length is what people mean when they say “2048-bit certificate” or “2048-bit key.” It’s baked into the cert and doesn’t change per session.

• DH modulus: this is the large prime p that defines the finite field the Diffie-Hellman exchange operates over. When DH is ephemeral (DHE), this prime is chosen or negotiated fresh, often for each session, and it's this value, not anything in the certificate, that ISM-0472 is actually asking about.

Seeing the difference yourself

The cleanest way to internalise this is to force a handshake and look at both values side by side. You’ll need a Linux box with OpenSSL to follow along. This is entirely self-contained, so no need to go hunting for a public server that still does classic DHE (more on why that’s hard, shortly).

1. Generate a cert and a DH group, then start a test server:

# The following command generates a self-signed cert with a 2048-bit RSA key.
# This is the “authentication” key.
openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem \
-days 7 -nodes -subj "/CN=test"

# The following command generates a 2048-bit DH parameter file. 
# This defines the DH modulus.
openssl dhparam -out dhparam2048.pem 2048

# The following starts a bare TLS server, forcing TLS 1.2 + DHE so nothing 
# negotiates around it.
openssl s_server -accept 4433 -cert cert.pem -key key.pem \
-dhparam dhparam2048.pem -no_tls1_3 -cipher 'DHE'

2. In a second terminal, connect and inspect both values:

openssl s_client -connect localhost:4433 -tls1_2 -cipher 'DHE' \
< /dev/null 2>/dev/null | grep -E "Temp Key|Server public key"

You’ll see something like:

Peer Temp Key: DH, 2048 bits
Server public key is 2048 bit

Two lines, two different keys, coincidentally matching. Now change just one of them and regenerate the DH params at 1024 bits and point the server at that file instead, and reconnect:

# The following command generates a 1024-bit DH parameter file. 
openssl dhparam -out dhparam1024.pem 1024

# The following command restarts the TLS server 
# but with the 1024-bit DH parameter file. 
openssl s_server -accept 4433 -cert cert.pem -key key.pem \
-dhparam dhparam1024.pem -no_tls1_3 -cipher 'DHE:@SECLEVEL=0'

# Note that you will need to force the weak key with `-cipher 'DHE:@SECLEVEL=0'`

Back in the other terminal (e.g., the “client side”), re-run the query:

openssl s_client -connect localhost:4433 -tls1_2 -cipher 'DHE:@SECLEVEL=0' \
< /dev/null 2>/dev/null | grep -E "Temp Key|Server public key"

# Note you need to force the weak cipher here too.

You will see:

Peer Temp Key: DH, 1024 bits
Server public key is 2048 bit

Same certificate. Same authentication strength. But the session key is now being negotiated over a modulus half the size. This demonstrates the gap the original evidence missed; nothing about the cert tells you what’s happening on that second line.

Where TLS 1.3 and ECDHE fit in

If you try to reproduce this against a real-world site instead of your own test server, you’ll almost certainly fail to find classic DH at all, and that’s the scenario worth paying attention to.

Most modern servers prefer elliptic-curve Diffie-Hellman (ECDHE) over classic finite-field DHE. It’s the same idea in terms of negotiating an ephemeral key exchange for the session, but the mathematics runs on an elliptic curve rather than a large prime field. Instead of a “modulus,” you’ll see something like:

Server Temp Key: X25519, 253 bits

That 253-bit figure isn’t directly comparable to a DH bit-length because elliptic curve math is far more efficient per bit. X25519 at 253 bits offers strength roughly on par with a 3000+ bit finite-field DH group. It’s arguably better than what ISM-0472 asks for. But it’s also a different mechanism entirely, so strictly speaking it falls outside ISM-0472’s scope (there’s likely a separate control for elliptic-curve parameters instead).

There’s a catch though: a server can support both. Under TLS 1.2, a server’s configuration can list ECDHE cipher suites and older DHE cipher suites side by side.

A default scan of the handshake will show ECDHE negotiated, because it’s preferred. But that doesn’t mean DHE isn’t still sitting in the config underneath, pointing at whatever DH parameters were set up years ago and never revisited. If nothing modern ever picks that path, nobody ever notices it as potentially weak. An assessor who only captures the default handshake and sees ECDHE could reasonably, but wrongly, conclude there’s no DH modulus to worry about at all.

You can prove this to yourself with the same test server, configured to allow both:

# Reuse the earlier cert, but point at the 2048-bit DH param file this time.
# Note we are using the 2048-bit DH param here instead
# of a 1024-bit to avoid the SECLEVEL quirk.

# Start the server allowing BOTH ECDHE and DHE cipher suites:
# no restriction to DHE only
openssl s_server -accept 4433 -cert cert.pem -key key.pem \
-dhparam dhparam2048.pem -no_tls1_3 -cipher 'ECDHE:DHE:@SECLEVEL=1'

Connect with an unrestricted client first. This is what a routine scan captures by default:

openssl s_client -connect localhost:4433 -tls1_2 < /dev/null 2>/dev/null \
| grep "Temp Key"

Peer Temp Key: X25519, 253 bits

Looks fine. Nothing to flag. Now force DHE specifically, to check what’s sitting underneath:

openssl s_client -connect localhost:4433 -tls1_2 -cipher 'DHE' \
< /dev/null 2>/dev/null | grep "Temp Key"

Peer Temp Key: DH, 2048 bits

Same server, same configuration, but two entirely different results depending only on which cipher suite gets negotiated. The first connection alone would have signed off on ISM-0472 as not applicable, but the second demonstrates that it does apply.

What about TLS 1.3?

TLS 1.3 removes this risk entirely, which is worth knowing about because it changed how DH is allowed to work. A TLS 1.2 server could hand the client any arbitrary DH prime it liked, which is how weak, sometimes reused, primes ended up in production undetected in the first place. TLS 1.3 only permits DH via a small set of pre-vetted groups, all 2048 bits or larger, so weaker moduli are architecturally impossible under TLS 1.3.

If a TLS 1.3 handshake negotiates DH at all, it’s already 0472-compliant by construction. The catch is that almost nobody implements it, as most stacks only wire up ECDHE for TLS 1.3, so a TLS 1.3 connection using classic DH at all is rare in practice. It’s TLS 1.2, still very much alive for backward compatibility, where the real risk sits.

The practical takeaway for an assessment

Put together, this gives you a decision path for actually testing this control properly:

• Enumerate everything the server supports, not just what a modern client negotiates by default. A tool like nmap —script ssl-enum-ciphers will show you the full cipher suite list, including any DHE suites that exist purely for backward compatibility but never get chosen in practice.

• If no DHE suites exist at all and the server only does ECDHE, then ISM-0472 doesn’t apply to the system; there’s no DH modulus in play anywhere.

• If DHE suites are present alongside ECDHE, don’t assume the default handshake tells the whole story. Force DHE explicitly (as shown above) and check what modulus size it actually falls back to. This is precisely the scenario just demonstrated. ECDHE is shown by default, but a DH group is still configured and reachable underneath.

• Even a “pass” here can come with a stronger recommendation. If DHE is present and checks out at 2048-bit or higher, that's technically compliant as far as ISM-0472 is concerned. But if every real client already supports ECDHE, nothing is actually relying on that DHE fallback, so the tighter finding is often “disable DHE entirely” rather than “leave it, it's compliant.”

None of this is really about DH being unusual or obscure. It's a reminder that “a strong key is present” and “the specific key this control asks about is strong” are two different claims, and it's worth knowing which one your evidence is actually making.

A matrix is a two-dimensional array that contains the same elements as the vector. A matrix can have m rows and n columns. If it does, it is called an m x n matrix. Consider the matrix A below.

Each element aij in the matrix is a numerical value displayed in row i and column j.

​Matrix addition

To add a matrix to another, the matrices must be of the same dimensions, and the elements need to be added to the correct corresponding index.

Consider again the matrix A.

The dimensions of matrix A are mxn, meaning that the matrix has m rows and n columns. Matrix A, therefore, can only be added to another matrix with m rows and n columns.

For example:

The addition is simple, provided that the dimensions match. Add element aij​ in A to the corresponding element bij in B.

Below is an example of D = A + B - C, where all matrices are of the same dimension.

If i = 2 and j = 3, then:

Which is:

That equates to:

Scalar multiplication of Matrix

When multiplying a matrix by a scalar, the dimensions and indices need not be verified. Each element of the matrix is simply multiplied by the scalar.

For example:

Where every element of the matrix A is multiplied by the scalar α.

Using real numbers, this could be:

Where every element of the matrix A is multiplied by the scalar 3.

Multiplication of Square Matrices

When multiplying two matrices, the dimensions must align correctly. Specifically, if you have a matrix A of dimensions m×n and a matrix B of dimensions p × q, multiplication is possible only if n = p. The resulting matrix C=AB will have dimensions m × q.

The most straightforward scenario is multiplying two square matrices of the same dimensions n × n. That is, both matrices have the same number of rows and columns.

Or to demonstrate with actual numbers:

Notice the pattern in finding each element cij in the resulting matrix C = AB: each element cij​ is calculated by taking the dot product of the i-th row of matrix A and the j-th column of matrix B. Specifically, this involves multiplying each element in the i-th row of A with the corresponding element in the j-th column of B, and then summing these products.

Here is a graphical illustration of this:

These illustrations demonstrate the first row and the first column (Cij):

If A is an n×m matrix and B is an m×p matrix, their matrix product AB will be an n×pmatrix. The way this product is calculated is as follows:

• Each entry in the resulting matrix AB is obtained by taking the corresponding row from matrix A and the corresponding column from matrix B.

• Specifically, you multiply each of the m elements in a row of A with the corresponding m elements in a column of B, and then sum these products. This sum becomes an entry in the matrix AB.

Example:

If A is 2×3 (2 rows, 3 columns) and B is 3×2 (3 rows, 2 columns), their product AB will be a 2×2 matrix.

Connection to Linear Transformations:

When matrices represent linear transformations (functions that map vectors to other vectors in a linear fashion), the matrix product AB represents the composition of these transformations. This means applying the transformation represented by B first, followed by the transformation represented by A. The resulting transformation is described by the matrix AB.

In essence, matrix multiplication corresponds to performing one transformation after another.

Non-Commutativity of Matrix Multiplication

An important observation in matrix algebra is that, in general, matrix multiplication is not commutative. This means that for two matrices A and B, the product A×B does not necessarily equal B×A.

For example, consider matrices A and B as follows:

When C=A×B element c23 in the resulting matrix is:

However, if the multiplication is reversed, C=B×A, the element becomes:

So, clearly

Which means A x B ≠ B = A.

This demonstrates that matrix multiplication is not commutative. This contrasts with scalar multiplication, where the order of multiplication does not affect the result. This non-commutativity is a fundamental characteristic of matrix operations.

If x, y, and z are variables, and a1​, a2, and a3 are scalars, then the following equation will be a linear combination.

If the variables are vectors, then the linear combination of a scalar by a vector will be a new vector:

The general notation of a vector by a scalar linear combination will be:

What is Span

The span of a set of vectors is the set of all possible linear combinations of those vectors.

Mathematically, the span of the set of vectors is written as:

This represents all possible vectors that can be formed by taking linear combinations of the vectors with real scalars.

In the case of two vectors in 2-dimensional space, if the vectors are not linearly dependent (i.e., they do not lie on the same line), their span will be the entire 2-dimensional space, meaning they can reach any point in that space. However, if the vectors are linearly dependent (i.e., they lie on the same line), their span is limited to all vectors along that line.

For example, the following three vectors would span the entire R3 space (the 3-dimensional vector space over the field of real numbers) because they are linearly independent. This means that no vector in the set can be expressed as a linear combination of the others, and together, they can represent any vector in R3

Span and 3-dimensional space

The concept of span is more interesting in 3D space. Take two vectors that are not pointing in the same direction. What does it mean to take their span?

In this case, the span of the two vectors is the set of all possible linear combinations of these vectors. Geometrically, this means that the span of these two vectors forms a plane in 3D space. Every vector (or point1) on this plane can be represented as a linear combination of the two original vectors.

Now, consider three vectors that are not all lying in the same plane. What happens when you take their span?

A linear combination of three vectors is essentially the same as it is in 2-dimensional space:

In 3D space, the span of three linearly independent vectors (that do not lie in the same plane) is the entire 3-dimensional space. This means that any vector/point in the space can be expressed as a linear combination of the three vectors.

So, the span of the vectors v, w, and u is the set of all possible vectors you can create by varying the scalars a, b, and c in the linear combination above. When these three vectors are linearly independent, their span covers all of 3D space.

Linear dependence

When a set of vectors is said to be linearly dependent, it means that at least one of the vectors in the set can be expressed as a linear combination of the others. In other words, some vectors in the set are redundant because they do not add any new direction (or span) to the vector space that the other vectors already cover.

In n-dimensional space, if a set of vectors is linearly dependent, the span of these vectors does not cover any additional directions beyond what is already covered by a subset of these vectors. Consequently, the set does not form a basis for the vector space, as a basis requires all vectors to be linearly independent, ensuring that they span the entire space without redundancy.

For example, take the following two vectors:

and:

These represent a linearly dependent set. Notice that each component of v2 is precisely one-fourth of the corresponding elements of v3.

Specifically:

This means v3 is simply a scaled version of v2. They are not independent because v3 can be written as a scalar multiple of v2. In other words, v2 and v3 lie along the same line in 3D space but at different magnitudes.

Visualising this concept in 3-dimensional space can be challenging. Consider a graphical representation with just two components in each vector for simplicity. As shown, the span of one vector is entirely encompassed by the other.

3Blue1Brown has great visualisations in his videos that better demonstrate exactly how this limits access to further span in a 3-dimensional vector space.

Linear independence

When each vector in a set of vectors can not be defined as a linear combination of the other vectors, they are said to be linearly independent.

That is, for all values of a:

Or for all values of a and b:

For example:

These vectors are linearly independent.

To check if the vectors are linearly independent, there should be no scalar, k, such that:

In other words, each component of v3 can not be equal to the corresponding components v1 multiplied by k.

For:

This would require:

To solve for k in the components:

The vectors are linearly independent since no single scalar k satisfies the equation for all components.

Again, this is challenging to represent on a 3-dimensional plane (see the video above!), but taking the first two components illustrates linearly independent vectors.

A note on basis vectors

The technical definition of a basis of a vector space is a set of linearly independent vectors that span the full space.

• Linearly Independent: No vector in the set can be written as a linear combination of the others. This ensures that all vectors in the basis contribute uniquely to spanning the space.

• Span: The set of vectors can be combined (through linear combinations) to form every possible vector in the space.

If you have a basis for a vector space, you can represent any vector in that space as a unique linear combination of the basis vectors.

î and ĵ are the “basis vectors” of the xy coordinate system.

In the xy coordinate system,

• î represents the unit vector in the direction of the x-axis.

• ĵ represents the unit vector in the direction of the y-axis

Whenever vectors are described numerically, it implicitly assumes a choice of basis vectors, typically î and ĵ in 2-dimensional Cartesian coordinates. Changing the basis vectors changes the representation of all vectors in that space, though the vectors themselves remain unchanged.

A system of Linear Equations

A linear combination of vectors by scalars is crucial in solving systems of linear equations. For instance, suppose a vector needs to be represented as a linear combination of two other vectors.

Consider the following vector:

Which needs to be the linear combination of:

In this situation, the equation solves for scalars a and b, where a and b represent the coefficients of x and y, respectively:

First, multiply each vector by its corresponding scalar:

Which is:

The above results gives two separate equations:

These equations form a system of two equations with two unknowns.

There are three theoretical methods to solve the equations.

Substitution Method

To solve a system of equations by substitution, first, isolate a variable from one of the equations and substitute it into the other. This reduces the system of equations to a single equation with a single unknown.

Equation 1

Equation 2

Step 1 - Solve one equation for one variable

Starting with Equation 2 for b in terms of a:

To isolate b, add b to both sides and subtract 2 from both sides:

Now b is expressed in terms of a.

Step 2 - Substitute the expression into the other equation

Substitute the expression for b from Equation 2 into Equation 1:

So Equation 1 goes from:

to:

Step 3 - Simplify and solve for a

Expand the equation:

Combine like terms:

Isolate the term with a by adding 10 to both sides:

becomes:

Divide both sides by -4 to solve for a:

Step 4 - Substitute back to find b

Now that a = 0.75, substitute this value back into the expression for b:

Substitute a = 0.75:

Which equals:

which is:

Step 5 - Verify the solution

To ensure the solution is correct, substitute a = -0.75 and b = -0.5 back into the original equations.

Check Equation 1

Substitute a for 0.75 and b for -0.5:

this equates to :

Check Equation 2

Substitute a for 0.75 and b for -0.5:

and equates to:

Final answer:

The solution to the system of equations is:

This solution satisfies both equations, confirming the calculations are correct.

Elimination Method

In this method, one of the variables is eliminated by enforcing the same absolute value for one of the coefficients (scalars) in the two equations.

The equations again are:

If Equation 2 is multiplied by 5, the equations become:

simplified to:

Step 1: Add the Equations

Now, add the two equations to eliminate b and obtain a single equation with a single unknown:

This becomes:

Combine like terms:

Step 2: Solve for a

To solve for a, isolate a by dividing both sides by -4:

Or:

Step 3: Substitute back to Find b

Now that a = 0.75, substitute this value back into the expression for b:

Substitute a = 0.75:

Which equals:

Subtract 1.5 from both sides:

Multiply both sides by -1:2

Final answer

This means scalars a = 0.75 and b = -0.5 represent the vector:

as a linear combination of vectors x and y.

Substituting the vectors

is:

is

Graphical Method

When using the graphical method to solve a system of linear equations by drawing the lines on a plane, calculate the following:

Step 1: Slope-Intercept Form of Each Equation:

The general form of a linear equation is y = mx + c, where:

• m is the slope of the line.

• c is the y-intercept (when x = 0).

For each equation, rearrange it into the slope-intercept form y = mx + c.

Given the system of equations:

Equation1:

To solve for b, isolate b on one side:

Now, divide by 5 to solve for b:

This is the slope-intercept form of the equation in terms of y = mx +c.

Equation 2:

To solve for b, isolate b on one side:

Now multiply the entire equation by -1 to solve for b:

This is the slope-intercept form of the equation in terms of y = mx +c.

Step 2: Plot the Lines:

Equation 1
Start by plotting the y-intercept at:

Use the slope to find another point. For every five units moved to the right, increase b by 13 units.

Equation 2

Start by plotting the y-intercept at:

Use the slope 2 to find another point. For each 1 unit moved to the right, b increases by two units.

Step 4: Find the Intersection Point:

The point where the two lines intersect is the solution of the system of equations.

This point corresponds to the values of x and y that satisfy both equations simultaneously.

In this case the point of intersection (the solution to the system of equations) is:

or:

• a = 0.75

• b = -0.5

Simply put, a vector is a list of ordered numbers. Each element in a vector is also called a component or coordinate.

In the example below, a vector (x) is in the field of Real Numbers with n-dimensions.1

The vector has infinite elements, as denoted by the ellipsis.

The following vector within a 2-dimensional field of Real Numbers has two elements.

This essentially represents a line on a 2-dimensional plane.

The elements of a vector give instructions on how to get from the origin of a coordinate grid (e.g., x = 0, y = 0). In other words, where the tail of the vector begins, to its tip.

The first number is how far to move to the right or left along the x-axis, while the second is how far to move up or down the y-axis.

In the vector above, the first element, 4, represents the movement along an x-axis. The second element, 2, represents the movement along a y-axis.

Visually, this could look like the following:

Starting from B, there are four movements to the right and then two movements vertically to reach A.

Mathematically, this would appear as:

Vector transpose

Vectors can be column vectors or row vectors. In Linear Algebra, a transpose is when a column vector takes the shape of a row vector or vice versa. The mathematical notation for a transpose is T.

In other words:

Magnitude

Each vector holds a magnitude.

The symbol used for magnitude is || ||.

The Pythagorean Theorem calculates the magnitude of a 2D vector.

For example, take the vector:

The magnitude would be calculated as:

Where 4 is the horizontal element (e.g., four movements along the x-axis) and 2 is the vertical element (e.g., two movements along the y-axis).

Direction

Therefore, the angle created by moving along the two axes gives the direction of the vector. Looking at the vector visually, the angle is denoted by θ.

Trigonometry is used to calculate the angle:

Where y is the short side of the triangle and x is the long side.

In this case:

Operations in the field

Vector addition

The mathematical definition of vector addition in the Real Numbers field is to add the elements entry by entry.

Take two vectors, for example:

The result of summing these two vectors will also be in the Real Numbers field.

For example, take these two vectors:

The sum of the first element:

is:

The sum of the second element:

is:

Therefore:

Visually, this is the same as moving the tail of the second vector to sit at the tip of the first.

Then drawing a new vector from the origin of the first vector to the tip of the second vector.

The resulting third vector is said to be the sum of the original two.

How does this look numerically?

In the example above, it is the same as:

• Five steps to the right (5)

• Two steps up (2)

• Four steps to the left (-4)

• One step down (-1)

Or :

• 5 + (-4) = 1

• 2 + (-1) = 1

Why is this a good definition of addition?

Think of each vector as a movement in space; a step with a distance and direction from some point of origin. Taking a step along the first vector and then a step along the second, the overall movement would be the same as the sum of the vectors, as described above.

It is the same as visualising movement on a one-dimensional number line. Taking two steps to the right and six further steps reaches position 8, just as if you were taking all eight steps simultaneously.

Scalar by vector multiplication

A scalar by vector multiplication is also defined by multiplying the vector elements entry by entry

If α∈R (that is, α is a number in the field of Real Numbers), and the vector is:

Then, each vector element is multiplied by the scalar (α).

Visually, scalar by vector multiplication extends the vector’s direction and increases or decreases the magnitude. Therefore, if the scalar is a fraction, the vector is reduced proportionally to that fraction.

Using a scalar of a negative number would flip the vector around to its opposite direction and then stretch it in that new direction.

Hence, the name “scalar” is used for scaling.

What is TTL

Time-to-live (TTL) is a computing mechanism that limits the lifespan or validity of data in a network. TTL is a value included in IP packets that tells a network router how many hops (transfers from one network segment to another) the packet is allowed before it should be discarded. The TTL value prevents data packets from circulating indefinitely and causing network congestion.

TTL values are set in the header of IP packets. The TTL value is an 8-bit field ranging from 0 to 255. The value set in this field determines the maximum number of routers (hops) the packet can pass through before it is discarded or dropped.

The initial TTL value of a packet can vary depending on the operating system or the application generating the packet. Some common initial values used by different systems include:

• Linux-based systems: 64

• Windows-based systems: 128

• Network equipment like Cisco routers: 255

The choice of the initial TTL value is a balance between ensuring that packets have enough hops to reach their destination under normal conditions and preventing packets from circulating unnecessarily, which is important to mitigate network congestion.

What Happens When the TTL Reaches 0

When the TTL value of an IP packet decrements to 0, it indicates that the packet has reached the maximum allowed number of hops (routers) without reaching its intended destination. The router that decrements the TTL value to 0 will discard the packet and typically send an ICMP (Internet Control Message Protocol) Time Exceeded message back to the source IP address. This ICMP message notifies the sender that the packet was not delivered due to the TTL expiring.

TTL Manipulation

Reconnaissance and Probing

Intentionally manipulating the TTL with lower-than-normal values can be used in network reconnaissance. By controlling the TTL value, a threat actor can elicit the ICMP Time Exceeded response from various appliances on a network. These responses can help infer the overall layout, map network paths, or identify the presence and location of specific appliances.

Bypassing Security Measures

Another application of TTL manipulation involves deceiving IDS and IPS appliances to smuggle malicious packets past these security controls.

This technique operates on the principle of sending two sets of packets with carefully selected TTL values and identical sequence numbers, exploiting the way some security devices handle packet inspection and filtering.

Initial Probing Packets: The threat actor sends a series of packets towards the target system with TTL values calibrated such that they expire right before reaching the target, yet after passing the IDS/IPS. These packets, designed to appear benign, prompt the IDS/IPS to log their sequences but ultimately discard them as they do not reach the destination due to TTL expiry.

Follow-Up Malicious Packets: Subsequently, the attacker sends another set of packets with identical sequence numbers as the probing packets, but this time, containing a malicious payload. These packets are sent with TTL values that ensure they reach the target. The critical manipulation here lies in setting the TTL of the probing packets to expire just beyond the IDS/IPS, thus avoiding further inspection of the subsequent malicious packets.

The IDS/IPS Deception: Many IDS/IPS configurations are optimised to reduce performance overhead, which includes minimising duplicate packet inspection. They might treat these follow-up packets as duplicates of the initial, already-checked sequence, thus not subjecting them to thorough scrutiny. Consequently, the packets carrying the malicious content bypass the IDS/IPS checks, reaching the target system unnoticed.

Incorporating Fragmentation with TTL Manipulation

Another method combines packet fragmentation with TTL manipulation to evade security controls. This technique leverages the fact that some security devices may not thoroughly inspect or reassemble fragmented packets.

By fragmenting malicious payloads and carefully setting the TTL values, attackers can craft packets that are less likely to be detected by traditional security mechanisms.

Fragmenting packets involves dividing the malicious payload into smaller fragments, making it more challenging for security devices to inspect packets and accurately identify and block harmful content.

Alongside fragmentation, the attacker manipulates the TTL values to ensure that the fragmented packets bypass the security devices with minimal scrutiny. The manipulated TTL values can help ensure that the fragments take a path through the network that avoids comprehensive inspection or takes advantage of devices that do not reassemble packets for inspection.

By carefully orchestrating the fragmentation and TTL settings, the attacker can potentially deliver the malicious payload past IDS, IPS, and firewalls. Once the fragments reach their target, they can be reassembled into the original malicious payload, executing the intended attack without being detected by the network’s security infrastructure.

Mitigation and Real-world Application

The effectiveness of these techniques in real-world scenarios can vary significantly. Modern Intrusion Detection and Prevention Systems are designed to mitigate such evasion tactics.

These systems often incorporate advanced algorithms and analysis of behaviour patterns to detect and counteract unusual TTL values and fragmented packet strategies.

To enhance network security against such TTL manipulation techniques, administrators can consider the following mitigation strategies:

• Enhanced Packet Inspection: Configure IDS/IPS to perform in-depth packet inspections, including analysing fragmented packets and verifying packet integrity.

• Anomaly Detection: Implement anomaly-based detection systems that identify unusual traffic patterns, including atypical TTL values.

• Regular Updates and Patching: Keep security devices updated with the latest software patches and threat intelligence to defend against new and evolving tactics.

• Comprehensive Security Practices: Employ a multi-layered security approach that includes encryption, firewalls, and end-to-end monitoring to reduce reliance on any single point of failure.

This advanced method illustrates the capacity for TTL manipulation in mapping network defences and its potential in crafting evasion strategies that exploit specific weaknesses in the security infrastructure’s logic and configuration.

Conclusion

Malicious TTL manipulation and packet fragmentation represent sophisticated evasion techniques that challenge traditional network security measures. Network administrators can better protect their infrastructure against these and other advanced threats by understanding and mitigating these tactics.

Introduction

When a GitHub repository is forked, it can maintain a connection with the original codebase, which is called the upstream repository or branch. This connection means that the forked repository can be modified as needed, but if changes are made to the original, such as new features, they can be integrated into the forked version.

This article outlines the steps to pull changes from an upstream repository into a forked version. Specifically, it outlines how to pull changes into a separate branch for testing and then how to merge those changes into the main branch of the fork after testing and resolving any conflicts1.

High-level workflow for Merging Upstream Changes:

1. Creating a New Branch: When upstream changes need to be merged, create a new branch in the forked repository based on the forked repository’s main branch.

2. Pulling Upstream Changes: Pull the changes from the upstream repository into this new branch. Resolve any conflicts here.

3. Testing: Use this branch to test the deployment to ensure everything works as expected. For example, if it’s a website, run it locally from the new branch, or if it’s a deployment, deploy from the branch to confirm everything is in order.

4. Creating a Pull Request: Once the branch with the upstream changes has been tested, create a Pull Request to merge this branch into the main branch. The Pull Request can be drafted during testing if necessary.

5. Review and Merge: Review the Pull Request in GitHub. After any necessary approvals, merge the Pull Request.

6. Delete the Branch: After the merge, the branch used to test the upstream changes can be deleted.

Prerequisites

• Ensure Git is installed on the system.

• Ensure access to the repository and its upstream repository.

Steps

1. Navigate to the local repo

2. Update the local main branch

Ensure the local main branch (or whichever branch will ultimately receive the tested upstream changes) is up to date with the remote repository.

git checkout main 
# Checkout the local copy of the main branch

git pull origin main 
# Pull remote changes into the local copy of the main branch

3. Fetch changes from the upstream repository

Fetch changes from the upstream repository without merging them.

git fetch upstream

4. Create a new branch for testing the upstream changes

Create a new branch based on the main branch to test the upstream changes.

This is important, as it protects the stability of the branch from which the code is deployed.

git checkout -b upstream-changes main 
# Create a new branch called upstream-changes based off the main branch

5. Merge upstream changes into the new branch

Merge the changes from the upstream repository into the new branch.

git merge upstream/main

Resolving merge conflicts

If there are merge conflicts, Git will pause the merge process and mark the files that have conflicts. Here is how to resolve them:

• Open the conflicted files in VS Code.

• Look for the areas marked as conflicts (usually indicated by <<<<<<, ======, and >>>>>>>).

• Manually edit the files to resolve the conflicts. Choose which changes to keep or combine as needed.

• After resolving conflicts, add the files to staging: git add .

• Then, continue the merge process: git merge --continue

• Once all conflicts are resolved and the merge is successful, proceed with the next steps.

6. Push the new branch to Github

It’s good practice to push the newly created branch with the upstream changes to the remote repository.

git push origin upstream-changes

7. Open a Pull Request in GitHub

Now, the Pull Request can be opened in draft.

Be careful that the Pull Request is proposing to pull the upstream-changes branch into your own main branch, and not the main branch of the upstream repository.

• Go to the repository in GitHub.

• Open a Pull Request for the upstream-changes branch against the main branch.

• This usually initiates any review process.

Do not merge it yet.

8. Deploy the Test branch

Deploy or run the upstream-changes branch locally, or undertake whatever steps are required to confirm the changes.

9. Review and merge the pull request

If the tests are successful, merge the changes into main by merging the pull request into the main branch through the GitHub interface2.

10. Update the local main branch and clean up

After merging the pull request, update the local main branch and then delete the test branch.

git checkout main 
# Switch back to the main branch

git pull origin main 
# Pull the remote version of main to the local copy so it is up-to-date with the recent merge

git branch -d upstream-changes 
# Delete the local copy of the branch used to test the upstream changes

git push origin --delete upstream-changes 
# Delete the remote copy of the branch used to test the upstream changes

11. Redeploy from the main branch

If required, it’s good practice to now re-deploy the codebase from the main branch.

Conclusion

This process ensures that changes from the upstream repository are tested in isolation before being integrated into the main branch, minimising the risk of disruption to the main codebase.

A quick note on Git Fetch vs. Git Pull

In Git, both git fetch and git pull are commands used to update local repository copies from a remote source. However, they serve different purposes and operate in distinct ways.

• git fetch retrieves updates from a remote repository but doesn’t automatically merge them into the current working branch. When git fetch upstream is executed, for instance, Git fetches any new work that has been pushed to the upstream repository since the last fetch, updating the local remote-tracking branches (like upstream/main). However, the working directory remains unchanged. This command is useful for reviewing changes before integrating them into the local branch.

• git pull, on the other hand, is a more aggressive command that not only fetches updates from the remote repository but also automatically merges them into your current working branch. Essentially, git pull is a combination of git fetch followed by git merge. When executed git pull origin main, Git fetches the changes from the main branch of the remote named origin and immediately attempts to merge them into the current working branch. This command is handy for quickly updating local branches with the latest changes from the remote, assuming they’re ready to be merged without a review process.

In Summary git fetch is when the changes require review before merging. Use git pull when integrating the remote changes immediately into the local branch without a preliminary review is not a concern.

Contents

• What is the Cyber Kill Chain Model?

• Applying the Human Element to Cyber Kill Chains

  • Reconnaissance

  • Weaponisation

  • Delivery

  • Exploitation

  • Installation (Persistence)

  • Command & Control (C2)

  • Actions on Objectives

• Conclusion

What is the Cyber Kill Chain Model?

The ‘kill chain’ concept is a borrowed military term that outlines the stages of an adversary’s attack methodology. Intercepting attackers at multiple points increases the likelihood of disrupting the threat or forcing the adversary to take more detectable actions.

The prevailing application of kill chain models focuses on technology and often overlooks the human element. Incorporating human aspects, like security awareness and end-user education, isn’t just another security control; it’s a unique approach to managing the fallibility humans introduce into any system or process.

Applying the Human Element to Cyber Kill Chains

Distilling a kill chain into its constituent steps is often highly context-dependent. In general, however, it can be conceptualised into the following categories:

• Reconnaissance

• Weaponisation

• Delivery

• Exploitation

• Persistence

• Command and Control

• Actions on objectives

The following will briefly consider the human element at each step and how it can disrupt or detect an attack.

Reconnaissance

The threat actor conducts preliminary information gathering.

Understanding their role as potential targets, an informed workforce or user base can significantly reduce information leakage by exercising caution on social media, verifying identities over the phone, and securely disposing of sensitive documents. While not a strategy that can mitigate the risk completely, these practices can impede an attacker’s reconnaissance efforts.

Weaponisation

The threat actor prepares appropriate tactics, techniques, and tools without direct contact with the target.

Limited security measures can disrupt this phase, except where a threat actor conducts preliminary testing on the target. In this case, an informed user base can act as additional “sensors” of Indicators of Compromise (IoCs).

Delivery

The threat actor launches the attack against the target.

While technical solutions strive to block this phase, human intuition and adaptability can also be crucial. People are often the first line of defence in recognising and countering attacks, especially those involving social engineering. Regular training and awareness programs can significantly enhance this human firewall.

Highly observant technical staff with a natural sense of curiosity and a keen eye for detail can also be invaluable. Take, for example, the case of a Microsoft Engineer who noted a few subtle but odd symptoms around a sub-component of a Linux package. After investigating, it ultimately led to the identification that the upstream packages had been backdoored.

Exploitation

The threat actor executes the attack by, for example, exploiting vulnerabilities.

Educated users are more likely to maintain updated systems and use security software, reducing the chances of successful exploitation. Awareness about phishing, suspicious links, and attachments can prevent many exploitation attempts.

Installation (Persistence)

The threat actor establishes persistence to a compromised target.

If an attack has reached this stage, technical solutions are arguably the best line of defence, but humans can still play a crucial role. With their daily interaction with systems, users are ideally positioned to notice anomalies in performance or behaviour that could be symptomatic of an attack. Encouraging users to report unusual activities can lead to early detection.

Command & Control (C2)

Compromised systems contact the threat actor’s external infrastructure for further instructions.

Proactive threat hunting aims to identify suspicious communications. Educated users who understand the importance of network hygiene and the signs of a compromised system can contribute by reporting unusual outbound traffic or behaviours.

Actions on Objectives

The threat actor pursues their ultimate goal within the compromised network.

Users' security-conscious behaviours—such as using strong passwords and scrutinising login activities—can complicate attackers’ efforts, enhancing the organisation’s detection capabilities and delaying lateral movement, data exfiltration, or privilege escalation. Encouraging a culture of security and vigilance can significantly disrupt an adversary’s ability to achieve their objectives.

Conclusion

Breaking a cyber kill chain is not solely the domain of technological solutions. Organisations can create a more robust defence against cyber threats by incorporating the human element at each stage. Security awareness and end-user education are critical components that enhance the overall security posture, making it more difficult for attackers to succeed.

Introduction

An older post resurrected from another platform because it will always be relevant.

Despite the recent high-profile breaches, the impact of the mosaic effect remains understated. This interactive article from ABC and the creator of Have I been Pwned visually (and scarily) gets the point across with mosaics! It is a timely reminder to minimise the PII we give out and not to reuse passwords.

What is the Mosaic Effect?

The mosaic effect demonstrates how seemingly innocuous pieces of information, when combined, can create a detailed and revealing picture of an individual’s identity, much like tiles forming a complete mosaic. No matter how insignificant each data breach may seem, it can contribute another tile to this unintended portrait. This piecemeal approach to data collection and the subsequent risk of re-identification in data sets that were thought to be anonymous or de-identified is an increasingly prominent concern in the digital age.

The risk also extends beyond the individual and into organizations. Inadvertent disclosure of sensitive information through various seemingly harmless data releases can lead to security vulnerabilities, making companies an unwitting participant in this digital patchwork of information.

What can you do?

Aside from minimising PII and not reusing passwords, the more cautious among us may want to consider using masked emails and pseudo-anonymising PII for online services.

Masked emails are aliases that forward to your real email, helping keep your actual email address out of the public domain. This can be a valuable tool in combating phishing attempts. Pseudo-anonymising data or replacing private identifiers with fake identifiers or pseudonyms can reduce the risk of identity theft or data misuse.

Password managers are more than just convenience tools; they’re a crucial component in the fight against the mosaic effect. They encourage strong, unique passwords for every account and service, making it difficult for attackers to decipher your digital identity even if they gain access to one set of credentials.

The mosaic effect underscores the need for a proactive approach to data privacy. By being vigilant about the data we share and how we protect it, we can thwart the efforts of those who seek to piece together our digital lives. Protecting our real identities only takes a little effort but can profoundly impact our digital security and privacy.

What is SOCKS

SOCKS stands for "SOCKet Secure" and is a protocol used for proxy servers. It operates at Layer 5 (Session Layer) of the OSI model, which means it can manage sessions and connections between different applications and servers. The protocol establishes a TCP connection to another server behind a firewall, allowing data to pass through a proxy server.

Is it tunnelling?

SOCKS can be considered a form of tunnelling. Here’s how it works in more detail:

• Connection Establishment: When a client wants to connect to a server behind a firewall, it first connects to the SOCKS proxy server. The proxy then establishes a connection to the target server on behalf of the client.

• Data Transmission: The data sent by the client is encapsulated within the SOCKS protocol and forwarded to the proxy server. The proxy server then decapsulates the data and sends it to the target server. This process effectively tunnels the data through the proxy server.

• Firewall Bypass: By encapsulating the data and routing it through the SOCKS proxy, the protocol can bypass firewall restrictions that might block direct communication between the client and the server. The firewall only sees the connection between the client and the proxy server, not the target server.

• Session Management: Operating at the Session Layer, SOCKS handles the establishment, maintenance, and termination of the session between the client and the target server. This ensures that the connection remains stable and data is transmitted reliably.

In summary, SOCKS acts as an intermediary that routes data between a client and a server, encapsulating and decapsulating the data to bypass firewalls and manage sessions effectively. This tunnelling capability makes it a powerful, secure, and flexible network communication tool.

Differences between SOCKS4 and SOCKS5

SOCKS4

• Protocol Support: Supports TCP only, making it suitable for applications that use this protocol for data transmission.

• Authentication: Doesn’t support authentication natively. Anyone with the proxy address and port can use it, which can be a security risk in open networks.

• Hostname Resolution: It cannot resolve hostnames; it requires the client to resolve the hostname to an IP address before initiating the connection.

• Use Case: Suitable for simple applications that require basic proxy functionality without the need for advanced security or UDP support.

SOCKS5

• Protocol Support: Supports both TCP and UDP, making it versatile for a wider range of applications, including those requiring real-time data transmission like VoIP.

• Authentication: Provides a range of authentication mechanisms, including:

  • No authentication

  • Username/password

  • GSS-API (Generic Security Services Application Program Interface) for more robust security needs.

• Hostname Resolution: Resolves hostnames, which means you can pass a domain name that SOCKS5 will resolve for you, simplifying client configurations.

• IPv6 Support: SOCKS5 can handle IPv6 addresses, making it compatible with modern networks.

• Use Case: Preferred for more complex environments where security, flexibility, and support for UDP are required.

Advantages of SOCKS5 over SOCKS4

1. Enhanced Security: SOCKS5 supports various authentication methods, ensuring that only authorised users can access the proxy.

2. Flexibility: Supports both TCP and UDP protocols, which is beneficial for applications requiring different types of data transmission.

3. Simplified Configuration: Can resolve hostnames and supports IPv6, reducing the complexity of client configurations.

4. Improved Performance: The ability to use UDP can lead to better performance in certain applications, such as gaming or streaming, where real-time data transmission is crucial.

Conclusion

SOCKS proxies are useful tools for navigating network restrictions and enhancing privacy. While SOCKS4 is simpler and sufficient for basic needs, SOCKS5 offers significant improvements in security, flexibility, and ease of use, making it the preferred choice for modern applications.

This version provides a more comprehensive overview of the SOCKS protocol and its versions by expanding on the details of authentication methods, hostname resolution, and use cases.