The full rule is this:
SecRule RESPONSE_BODY "(?:<title>[^<]*?(?:\b(?:(?:c(?:ehennemden|gi-telnet)|gamma web shell)\b|imhabirligi phpftp)|(?:r(?:emote explorer|57shell)|aventis klasvayv|zehir)\b|\.::(?:news remote php shell injection::\.| rhtools\b)|ph(?:p(?:(?: commander|-terminal)\b|remoteview)|vayv)|myshell)|\b(?:(?:(?:microsoft windows\b.{0,10}?\bversion\b.{0,20}?\(c\) copyright 1985-.{0,10}?\bmicrosoft corp|ntdaddy v1\.9 - obzerve \| fux0r inc)\.|(?:www\.sanalteror\.org - indexer and read|haxplor)er|php(?:konsole| shell)|c99shell)\b|aventgrup\.<br>|drwxr))" \
"phase:4,rev:'2',ver:'OWASP_CRS/2.2.9',maturity:'8',accuracy:'8',t:none,ctl:auditLogParts=+E,block,msg:'Backdoor access',logdata:'Matched Data: %{TX.0} found within %{MATCHED_VAR_NAME}: %{MATCHED_VAR}',capture,id:'950922',tag:'OWASP_CRS/MALICIOUS_SOFTWARE/TROJAN',tag:'WASCTC/WASC-01',tag:'OWASP_TOP_10/A7',tag:'PCI/5.1.1',severity:'2',setvar:'tx.msg=%{rule.msg}',setvar:tx.trojan_score=+1,setvar:tx.anomaly_score=+%{tx.error_anomaly_score},setvar:tx.%{rule.id}-OWASP_CRS/MALICIOUS_SOFTWARE/TROJAN-%{matched_var_name}=%{matched_var}"
This does match above because of the last test: drwxr. I'm not sure why this was added to this rule as there's no explanation in the comments, and this was in the 2.6 version originally committed to GitHub.
Anyway you've several options:
You could edit the rule to remove that last check. This is not recommended, since any future upgrade of your rules will reinstate it.
You could just turn off that rule by adding the following to your config (after you have loaded the rule from /dh/apache2/template/etc/mod_sec2/modsecurity_crs_45_trojans.conf)
SecRuleRemoveById 950922
You could also turn off response body parsing:
SecResponseBodyAccess Off
Scanning response bodies can affect performance so you should consider this anyway. Requests are typically small (e.g. GET /index.html) but responses will contain a lot more data.
In theory you should know what is in your responses (providing you have protection against SQL injections and XSS and the like), so it might not make sense to scan outbound responses.
The counter argument is that response body checking is useful for preventing information leakage (e.g. a SQL injection attack which is used to leak information from your database). Then again if you allow a SQL injection you are in deep trouble anyway even without leaking information.
Personally I don't find scanning response bodies that useful except in specific use cases so have them off by default and turn them on for certain URLs.