React2Shell Detection Efforts - Part 2
Given that we now have an understanding on what to expect and how this exploit works, we can proceed to refine a better approach to find these events.
For example, a recent intelligence brief (Thank you Greynoise), revealed that the most common exploitation technique abuses keywords and patterns seen in JS prototype pollution
JSON
{
"then": "$1:__proto__:then", // This right here
"status": "resolved_model",
"reason": -1,
"value": "{\"then\":\"$B1337\"}",
"_response": {
"_prefix": "[MALICIOUS_JAVASCRIPT_CODE]",
_chunks": "$Q2",
"_formData": {"get": "$1:constructor:constructor"}
}
}
And that the exploit events can be grouped into attack patterns, like arithmetic calculations (payload had math operations contained), script execution (payload had poweshell or shell scripts), cross platform commands (usage of unix/windows commands was detected), so on and so forth
So, with this extra information at hand, we can improve our draft , and make something simple, like a bash script to look at our network logs abusing prototype pollution
#!/bin/bash
LOG_FILE="$1"
RED='\033[0;31m'
YELLOW='\033[1;33m'
WHITE='\033[0m'
echo -e "Starting log scan on $LOG_FILE for React 2 Shell indicators...${WHITE}"
echo "--------------------------------------------------------"
PATTERN_R2S_CORE="(__proto__|constructor|resolved_model|\"then\"\s*:\s*\"\\$|\"then\":\"\\$)"
PATTERN_SYS_INFO="(whoami|uname\s+-[a-zA-Z]|hostname|cat\s+/etc/passwd|/etc/shadow|id\s+-u|pwd|net\s+user|ipconfig|ifconfig)"
log_scan() {
local r2s_pattern_name="$1"
local r2s_regex_pattern="$2"
local color="$3"
echo -e "${color}[*] Looking for $r2s_pattern_name...${WHITE}"
MATCHES=$(grep -E -i -n "$r2s_regex_pattern" "$LOG_FILE")
if [ ! -z "$MATCHES" ]; then
echo -e "${RED}>>> POTENTIAL $r2s_pattern_name DETECTED:${WHITE}"
echo "$MATCHES"
echo "--------------------------------------------------------"
else
echo "No matches found for $r2s_pattern_name."
echo "--------------------------------------------------------"
fi
}
log_scan "R2S EXPLOIT SIGNATURES (Proto Pollution)" "$PATTERN_R2S_CORE" "$YELLOW"
echo -e "Scan finished.${WHITE}"-
This, can even be further translated into detection rules, for example, one for Suricatta
alert http $EXTERNAL_NET any -> $HTTP_SERVERS any ( \
msg:"LOCAL React 2 Shell Exploit Attempt"; \
flow:established,to_server; \
pcre:"/(__proto__|constructor|resolved_model|\x22then\x22\s*:\s*\x22\\$)/P"; \
classtype:web-application-attack; \
sid:1000001; \
rev:1; \
)
Even a Splunk detection
index=web_logs sourcetype=source_type
| search "*__proto__*" OR "*constructor*constructor*" OR "*resolved_model*"
OR "\"then\":\"$*" OR "\"then\"\\s*:\\s*\"$*"
| transaction clientip maxspan=5m
| table _time, clientip, useragent, http_method, uri, status, referrer, request_body
| rename clientip AS "Source IP", useragent AS "User Agent", http_method AS "Method",
uri AS "URI", status AS "Status", referrer AS "Referrer", request_body AS "Request Body"
| where like(request_body, "%__proto__%")
OR like(request_body, "%constructor%constructor%")
OR like(request_body, "%resolved_model%")
OR like(request_body, "%\"then\":\"$%")
Once there is a general understanding on how the vulnerability works, and we have identified a pattern we can look for in our logs, translation to any other SIEM detection is possible.
As always, further refinement is needed (Rules are too specific and may not work in some instances), and there are a lot of improvements we can make here, like the fact that these queries are memory expansive (Example, the search in the Splunk rule looks at the entire request) and most likely noise generators (There are multiple scenarios not contemplated here that I'm still looking at), but this could be a great start.
Further readings