I just had a look myself, and it's not as simple as you would hope. Let's reverse engineer and see what I mean.
We start with what we know: the first byte in the PPU RAM that we're interested in is at $23CC. It's A0, which is 1010 0000 in binary. This means the bottom left and right tiles use palette 2 while the top left and right use palette 0. Changing A0 to 50 (0101 0000) would make them use palette 1 instead (the brick palette). The question is, where did the game get this A0, and how do we change it to 50?
I set a write breakpoint for $23CC and see that it comes from $3B5 in RAM, where I can see 23 CC 01 A0. Having worked on early Nintendo games before, I know what this means: start at $23CC, write 1 byte, here it is. Now we need to know how THAT got into RAM. Set a write breakpoint for $3B5 and start again from the lives screen.
This is where it gets tricky. This section of RAM is repeatedly used for doing the PPU writing, so I get numerous breakpoint hits. After clicking through some of the ones I can see that I don't need, I find one where we get 23 CC 01 A0 at that point, and here it's easier to do a trace log file to see everything that led to this point, so I do that and start working backwards.
So the A0 actually comes from $3F9, not far away, so let's see where that came from... well, by going back further, I can see that originally it had 20, not A0, and it became A0 through an OR against the value at $0003 which is 80. I know this all sounds like gibberish at this point, but bear with me.
My guess is the 20 refers to the palette of one of the four tiles (being palette 2), and the OR is because it must combine with the palette of another tile to produce one byte with both palettes. Hmm...
At this point my brain is melting and I'm having trouble following what's going on. I've exhausted my abilities here, and reading the SMB disassembly isn't helping me much. Maybe someone else wants to pick up where I left off?