Seeking advice on next steps in investigation
-
Hello everyone,
Seeking advice on how to best deal with a possible compromised IoT device.So the background on this is that i have several vlans in my environment. One of the vlans is my IoT vlan where anything wireless / non critical goes in here. The firewalls permit his to only outbound internet and cannot access any of the LANs.
Tonight i decided to turn on Suricata on the WAN as i do have inbound rules permitting specific sources to my DMZ all handled through a reverse proxy and some rules for outside monitoring of my WAN interface and Remote Access (Geo Fenced with pfBlocker)
While reviewing the logs i noticed that a particular flow kept recurring. The signature being matched is '"ET JA3 Hash - Trojan.AndroidOS.Jocker.snt 1"; ja3_has'
Working backwards i was able to trace it to an internal host in my IoT domain. It goes to a Nixplay digital frame. These devices do run Android in the background. Checking the destination in virus total, the IP is clean but still unsure if this is a legimate threat or the pattern matcher confusing a legitimate flow for a threat.
Am i worried? If i didnt have the restrictive rule for IoT i would be but for now im not sure how to best rule out this issue. Seeking advice from the community here.
-
@michmoor said in Seeking advice on next steps in investigation:
ET JA3 Hash - Trojan.AndroidOS.Jocker.snt
That IP address is listed as part of a large /13 Amazon Web Services IP block, and that type of digital picture frame (Nixplay) is listed as being compatible with Amazon photos. So, my first inclination is to think this is simply the digital picture frame accessing a collection of photo JPGs off the Amazon cloud infrastructure.
Although the spelling is not the same, there is an Android trojan listed from about 2020 called SysJoker (or Joker) that was used mostly for advertising click fraud apparently. While that could be possible, I'm more inclined to think you are seeing a false positive from the digital frame simply pulling photos off an Amazon cloud server. If the flow consistently re-establishes to the same IP address or IP block, then that bolsters the false positive case in my view since that block belongs to Amazon. Doesn't mean the bad guys could not be be sitting on AWS infrastructure, but still don't think that's too likely.
-
@bmeeks It is reaching out to Amazon blocks 3.0.0.0/9 and 52.88.0.0/13
Dont remember how photos were placed in the digital frame. Couldve been done through USB or through initial setup or through the app.
The signature being fired is really throwing my spidy senses in a frenzy. Its not uncommon for a CnC VPC to be turned up quickly.
Firewall: NetGate,Palo Alto-VM,Juniper SRX
Routing: Juniper, Arista, Cisco
Switching: Juniper, Arista, Cisco
Wireless: Unifi, Aruba IAP
JNCIP,CCNP Enterprise -
@bmeeks said in Seeking advice on next steps in investigation:
If the flow consistently re-establishes to the same IP address or IP block, then that bolsters the false positive case in my view since that block belongs to Amazon. Doesn't mean the bad guys could not be be sitting on AWS infrastructure, but still don't think that's too likely.
We're pretty much thinking the same thing.
But as i mentioned there are two different IP blocks that this frame is reaching out on.
Im inclined to put this on a sepearte remediation vlan with no internet until i can figure out a way to tshoot this further but its an IoT device so the risk is low. -
@michmoor said in Seeking advice on next steps in investigation:
@bmeeks It is reaching out to Amazon blocks 3.0.0.0/9 and 52.88.0.0/13
Dont remember how photos were placed in the digital frame. Couldve been done through USB or through initial setup or through the app.
The signature being fired is really throwing my spidy senses in a frenzy. Its not uncommon for a CnC VPC to be turned up quickly.
Well, if the network the device is sitting on can only access the web and not any internal network, then it can't compromise your internal trusted networks. And if it is constantly connecting to the same IP space, and that space is Amazon, then it's not doing much in the way of malware. True malware, once it gets instructions from the mothership, then turns its attention to other IP addresses scanning for victims or something. A digital picture frame is not going to be a high horsepower device, and thus is of limited usefulness for most bad actors.
See if the firewall is showing any other outbound connections for that digital frame. If the only connections go to Amazon, I don't think I would sweat it much - especially since it's on an isolated network with only outbound Internet access.
That frame seems to offer quite a few features. Have a look here: https://www.nixplay.com/pages/help. It lets you invite friends to share photos. You do this through a phone app.
-
@bmeeks said in Seeking advice on next steps in investigation:
See if the firewall is showing any other outbound connections for that digital frame. If the only connections go to Amazon, I don't think I would sweat it much - especially since it's on an isolated network with only outbound Internet access.
Good idea. I turned on ntopng to gain some incites into the flows.
The pearls of TLS in the cybersecurity world :(Firewall: NetGate,Palo Alto-VM,Juniper SRX
Routing: Juniper, Arista, Cisco
Switching: Juniper, Arista, Cisco
Wireless: Unifi, Aruba IAP
JNCIP,CCNP Enterprise -
UDP Port 4070 is used for Tripe (Trivial IP Encryption). Spotify is one user of that port and protocol it seems. There may be others. That Amazon IP might actually simply be the "cloud location" run by the Nixplay company to facilitate photo sharing and the other features they mention are available through their app interacting with the digital frame. The frame would need to maintain a connection to the Nixplay "mothership" in order to interact with the cloud app features I would think.
-
@michmoor Sounds like it’s a bit late now but if you run Suricata on the internal (physical) interface of the VLAN it would tell you the internal IP of the devices.
You could make a temporary firewall rule logging all traffic from that IP.
-
@SteveITS hey Steve! I traced it back to the device internally and I log all flows to my remote log server.
I’m just going to have to monitor this device fora few before I rule out a false positive -
@bmeeks that’s a reasonable assumption of the flow.
The risk level here is low but that rule that triggered just had me concerned.
I’m going to monitor for a few before I rule out but so far the endpoints it’s connecting to are clean in virus total. -
@michmoor said in Seeking advice on next steps in investigation:
The pearls of TLS in the cybersecurity world :(
You should still be able to sniff the traffic and in the handshake see the sni its going to.. This would/should be some validation that talking to something about the pictureframes, and not some odd ball domain being hosted on aws space doing bad shit, etc.
-
I once got the advice here to turn off internet for IoT and only to enable it for updates etc.
-
I appreciate everyones feedback here.
Letting ntopng run for a few hours so new flows could be seen and analyzed this issue can be concluded as a false positive for env.
Checking DNS queries along with TLS Hellos for the CN shows that all outbound connections appear to be related and are part of the normal flows a product like this would make.
-
@michmoor said in Seeking advice on next steps in investigation:
can be concluded as a false positive for env.
No say it isn't so - and IPS/IDS with false positive.. Can't be! ;) hehehehe
-
@johnpoz LOL
edit: This was a pretty good lesson/refresher for me to go through and break down how to investigate an alert. I hope i was clear in my approach to help others after me.
-
@michmoor said in Seeking advice on next steps in investigation:
his was a pretty good lesson/refresher for me to go through and break down how to investigate an alert.
You might consider posting feedback to the Emerging Threats/ProofPoint team on the false positive of that rule Signature. I suspect it was written a bit "loose" on the pattern matching end. There are likely other innocent Android-based devices that may also trigger that alert needlessly. Supplying them some packet captures would be helpful to them along with your other findings.
Rule authors sometimes get too focused on some "thing" a piece of malware is doing and may fail to fully recognize that some behavior is "just the way it works" with a certain operating system. I have not examined the rule in question here, but it may be that the trojan this rule was originally created to detect does a number of things using normal Android API techniques in addition to the trojan's "not normal" things. Very important for all those to be carefully filtered and analyzed by the rule's detection logic to reduce such false positives. For instance, if a lot of Android apps generate traffic of type "X", and your target trojan also generates traffic of type "X", then using solely traffic type "X" as the trigger for the rule is a bad design. In that case the rule needs to look for multiple triggers, and logically AND them together before deciding on whether an alert is appropriate.
-
@bmeeks Thanks Bill. Ill reach out to them on their forum and on Twitter.
