X
Tap here to go to the mobile version of the site.

Support Forum

Generic Indicator of Compromise Detected Due to Unicode RtoL Encoding in Firefox Command Line - Is RtoL Expected Behaviour or a Genuine Compromise?

Posted

Hello support community,

 Our Cisco AMP advanced malware protection has detected more than one instance it considers a generic IOC (indicator of compromise) for Firefox 59.0.2.6656 for Windows (32-bit - Application SHA-256: e1010feb5e9d4726c2a8bf092d3f00521cccb2ee7189273eeb8d297a469104b9) and we aren't sure if it is legitimate Firefox behaviour or not as it is indeed out of the ordinary.
 AMP detected the following command line being invoked with unicode right-to-left used -- file path characters are actually reversed into "right-to-left" order in the command line (see the last bit of the command line), which is not expected behaviour in our locale:

--- [begin command line] --- C:\Program Files (x86)\Mozilla Firefox\firefox.exe -contentproc --channel=9592.3.567747140\910701300 -childID 1 -isForBrowser -intPrefs 6:50|7:-1|34:1000|42:20|43:5|44:10|51:0|57:128|58:10000|63:0|65:400|66:1|67:0|68:0|69:100|74:0|75:120|76:120|159:2|160:1|164:60|165:30|166:512000|175:5000|177:6|191:8192|192:524288|193:5|206:10000|227:24|228:32768|230:0|231:0|240:5|244:1048576|246:100|247:5000|249:600|251:1|260:2000|277:4|281:0|290:60000|308:300|309:30| -boolPrefs 1:0|2:0|4:1|5:0|24:1|27:0|28:1|29:1|31:1|32:1|33:1|36:0|37:0|38:1|41:1|45:1|46:0|47:0|48:1|49:1|50:1|52:0|55:1|56:1|59:0|60:0|61:0|62:0|64:0|70:1|71:1|72:0|73:1|77:1|78:1|79:0|80:0|81:1|82:1|83:0|84:1|87:0|88:0|91:1|92:1|96:1|97:1|98:0|99:1|100:0|101:0|103:0|104:0|105:1|106:1|107:1|110:1|111:1|112:1|113:1|114:1|115:0|116:0|117:0|119:0|120:1|121:1|122:0|123:0|124:0|125:0|127:1|128:0|129:1|130:1|131:1|132:0|133:0|134:1|135:1|136:1|137:1|138:0|139:1|140:1|141:1|142:1|143:1|144:1|145:0|146:1|147:1|148:0|149:1|150:0|152:0|153:0|154:0|155:1|156:1|157:1|158:1|161:1|162:0|172:0|173:0|174:1|178:1|181:0|182:1|184:1|186:0|188:1|194:1|195:0|196:1|197:1|198:0|201:1|205:1|207:1|208:0|210:1|213:0|219:0|220:1|221:0|222:1|225:0|226:0|229:1|232:0|234:1|235:1|237:1|238:0|245:1|248:1|253:0|254:0|255:0|256:1|257:1|258:0|259:1|264:0|267:1|268:1|269:1|270:1|271:1|272:0|273:0|279:0|282:0|283:0|284:1|285:1|286:0|287:1|288:1|289:1|291:0|292:0|294:0|303:1|304:1|305:0|306:0|307:0| -stringPrefs 3:7;release|151:0;|212:3;1.0|223:332; ¼½¾ǃː̷̸։֊׃״؉؊٪۔܁܂܃܄ᅟᅠ᜵           ​‎‏‐’․‧

‪‫‬‭‮ ‹›⁁⁄⁒ ⅓⅔⅕⅖⅗⅘⅙⅚⅛⅜⅝⅞⅟∕∶⎮╱⧶⧸⫻⫽⿰⿱⿲⿳⿴⿵⿶⿷⿸⿹⿺⿻ 。〔〕〳゠ㅤ㈝㈞㎮㎯㏆㏟꞉︔︕︿﹝﹞./。ᅠ�|224:4;high|278:38;{9236dabd-96ba-42e3-bed1-f4c6cc7b7361}| -schedulerPrefs 0001,2 -greomni C:\Program Files (x86)\Mozilla Firefox\omni.ja -appomni C:\Program Files (x86)\Mozilla Firefox\browser\omni.ja -appdir C:\Program Files (x86)\Mozilla Firefox\browser 9592 \\.\pipe\gecko-crash-server-pipe.9592 tab‬‬‬ --- [end command line] ---

 As this is detected as a generic IOC, it's not a question we can pose to Cisco AMP support, it's one we need to address to the Mozilla support community.
 Can you please advise if this is normal Firefox behaviour or if it is indeed an indicator of compromise? If it is normal behaviour, might you also be able to advise why this encoding is used for locales that do not use RtoL unicode?

Thank you

Hello support community, Our Cisco AMP advanced malware protection has detected more than one instance it considers a generic IOC (indicator of compromise) for Firefox 59.0.2.6656 for Windows (32-bit - Application SHA-256: e1010feb5e9d4726c2a8bf092d3f00521cccb2ee7189273eeb8d297a469104b9) and we aren't sure if it is legitimate Firefox behaviour or not as it is indeed out of the ordinary. AMP detected the following command line being invoked with unicode right-to-left used -- file path characters are actually reversed into "right-to-left" order in the command line (see the last bit of the command line), which is not expected behaviour in our locale: --- [begin command line] --- C:\Program Files (x86)\Mozilla Firefox\firefox.exe -contentproc --channel=9592.3.567747140\910701300 -childID 1 -isForBrowser -intPrefs 6:50|7:-1|34:1000|42:20|43:5|44:10|51:0|57:128|58:10000|63:0|65:400|66:1|67:0|68:0|69:100|74:0|75:120|76:120|159:2|160:1|164:60|165:30|166:512000|175:5000|177:6|191:8192|192:524288|193:5|206:10000|227:24|228:32768|230:0|231:0|240:5|244:1048576|246:100|247:5000|249:600|251:1|260:2000|277:4|281:0|290:60000|308:300|309:30| -boolPrefs 1:0|2:0|4:1|5:0|24:1|27:0|28:1|29:1|31:1|32:1|33:1|36:0|37:0|38:1|41:1|45:1|46:0|47:0|48:1|49:1|50:1|52:0|55:1|56:1|59:0|60:0|61:0|62:0|64:0|70:1|71:1|72:0|73:1|77:1|78:1|79:0|80:0|81:1|82:1|83:0|84:1|87:0|88:0|91:1|92:1|96:1|97:1|98:0|99:1|100:0|101:0|103:0|104:0|105:1|106:1|107:1|110:1|111:1|112:1|113:1|114:1|115:0|116:0|117:0|119:0|120:1|121:1|122:0|123:0|124:0|125:0|127:1|128:0|129:1|130:1|131:1|132:0|133:0|134:1|135:1|136:1|137:1|138:0|139:1|140:1|141:1|142:1|143:1|144:1|145:0|146:1|147:1|148:0|149:1|150:0|152:0|153:0|154:0|155:1|156:1|157:1|158:1|161:1|162:0|172:0|173:0|174:1|178:1|181:0|182:1|184:1|186:0|188:1|194:1|195:0|196:1|197:1|198:0|201:1|205:1|207:1|208:0|210:1|213:0|219:0|220:1|221:0|222:1|225:0|226:0|229:1|232:0|234:1|235:1|237:1|238:0|245:1|248:1|253:0|254:0|255:0|256:1|257:1|258:0|259:1|264:0|267:1|268:1|269:1|270:1|271:1|272:0|273:0|279:0|282:0|283:0|284:1|285:1|286:0|287:1|288:1|289:1|291:0|292:0|294:0|303:1|304:1|305:0|306:0|307:0| -stringPrefs 3:7;release|151:0;|212:3;1.0|223:332; ¼½¾ǃː̷̸։֊׃״؉؊٪۔܁܂܃܄ᅟᅠ᜵           ​‎‏‐’․‧

‪‫‬‭‮ ‹›⁁⁄⁒ ⅓⅔⅕⅖⅗⅘⅙⅚⅛⅜⅝⅞⅟∕∶⎮╱⧶⧸⫻⫽⿰⿱⿲⿳⿴⿵⿶⿷⿸⿹⿺⿻ 。〔〕〳゠ㅤ㈝㈞㎮㎯㏆㏟꞉︔︕︿﹝﹞./。ᅠ�|224:4;high|278:38;{9236dabd-96ba-42e3-bed1-f4c6cc7b7361}| -schedulerPrefs 0001,2 -greomni C:\Program Files (x86)\Mozilla Firefox\omni.ja -appomni C:\Program Files (x86)\Mozilla Firefox\browser\omni.ja -appdir C:\Program Files (x86)\Mozilla Firefox\browser 9592 \\.\pipe\gecko-crash-server-pipe.9592 tab‬‬‬ --- [end command line] --- As this is detected as a generic IOC, it's not a question we can pose to Cisco AMP support, it's one we need to address to the Mozilla support community. Can you please advise if this is normal Firefox behaviour or if it is indeed an indicator of compromise? If it is normal behaviour, might you also be able to advise why this encoding is used for locales that do not use RtoL unicode? Thank you
Attached screenshots

Additional System Details

Installed Plug-ins

  • Shockwave Flash 28.0 r0

Application

  • User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:59.0) Gecko/20100101 Firefox/59.0

More Information

Shadow110 1072 solutions 14836 answers

Hi, this would not be the best place to get a answer for that as is Support Volunteers and not Developers/engineers. It is also a open forum.

If you have a bug, file a bug report. https://bugzilla.mozilla.org/ Bug Writing Guidelines : https://developer.mozilla.org/en-US/docs/Mozilla/QA/Bug_writing_guidelines

Please let us know if this solved your issue or if need further assistance.

Hi, this would not be the best place to get a answer for that as is Support Volunteers and not Developers/engineers. It is also a open forum. If you have a bug, file a bug report. https://bugzilla.mozilla.org/ Bug Writing Guidelines : https://developer.mozilla.org/en-US/docs/Mozilla/QA/Bug_writing_guidelines Please let us know if this solved your issue or if need further assistance.

Question owner

This isn't a bug report, it's a question of whether or not this is expected behaviour. If there is a more appropriate place to ask the question we are open to using it, but it would not make sense to submit a bug report for what is likely either expected behaviour or a compromise, neither of which are bugs.

This isn't a bug report, it's a question of whether or not this is expected behaviour. If there is a more appropriate place to ask the question we are open to using it, but it would not make sense to submit a bug report for what is likely either expected behaviour or a compromise, neither of which are bugs.
Shadow110 1072 solutions 14836 answers

pa_am said

This isn't a bug report, it's a question of whether or not this is expected behaviour. If there is a more appropriate place to ask the question we are open to using it, but it would not make sense to submit a bug report for what is likely either expected behaviour or a compromise, neither of which are bugs.

Hi again. Volunteer Support can not answer your question. Please follow that by filing a bug report and someone that knows will figure it out.

We do not do that sort of stuff thing here and do not have the knowledge to even begin to answer you.

''pa_am [[#answer-1095833|said]]'' <blockquote> This isn't a bug report, it's a question of whether or not this is expected behaviour. If there is a more appropriate place to ask the question we are open to using it, but it would not make sense to submit a bug report for what is likely either expected behaviour or a compromise, neither of which are bugs. </blockquote> Hi again. Volunteer Support can not answer your question. Please follow that by filing a bug report and someone that knows will figure it out. We do not do that sort of stuff thing here and do not have the knowledge to even begin to answer you.

Question owner

Appreciate the responses, but again this is not a bug. So, while it may not be the appropriate place to ask the question (noted), submitting a bug report for a non-bug is not appropriate either and that shouldn't be the recommendation.

Thank you

Appreciate the responses, but again this is not a bug. So, while it may not be the appropriate place to ask the question (noted), submitting a bug report for a non-bug is not appropriate either and that shouldn't be the recommendation. Thank you
cor-el
  • Top 10 Contributor
  • Moderator
17526 solutions 158458 answers

You will have to contact Cisco because they are they only one that can tell what this data represents.

You will have to contact Cisco because they are they only one that can tell what this data represents.