Suricata has picked up some easy things to get started on, so let’s start there.
Of particular interest to me (not that the others aren’t interesting), are the executable signatures; so let’s filter out the
opendns[.]com lookups for now. This takes us down to a single source and destination to focus on,
Hopping over to the Discover tab, when we apply the source IP from the previous step, we see only 8 events…definitely manageable. Let’s get rid of the
alert dataset because we know about those from the Suricata dashboard.
Now that we’ve used the metadata to get down to a single IP address as the potential bad actor, let’s use Docket to carve the packets for that IP and see what it can tell us. Using Wireshark on these packets, we follow the TCP stream and see this URL and a downloaded PE executable.
Exporting the HTTP object gives us the PE file, which we can analyze as well.
exiftool, we can see some interesting info, mainly that the original file was called
soldier.dll and that the File Type is
Win32 EXE (truncated).
$ exiftool lastimg.png ... File Name : 215z9urlgz.php%3fl=xubiz8.cab File Type : Win32 EXE File Type Extension : exe MIME Type : application/octet-stream Image File Characteristics : Executable, 32-bit PE Type : PE32 Original File Name : soldier.dll ...
Checking with VirusTotal, we see that the file hash is known bad so this looks like a good find!
Now that we have a few more hints to search through, specifically
qr12s8ygy1[.]com, let’s go back to Kibana and remove the stuff we’ve already found and see if we can find anything else.
settings-win.data.microsoft.com appears to be a Microsoft botnet sinkhole, so while we can use some of the info, I’m going to remove this from our searches to eliminate traffic routes to chase. Additionally, I’m filtering out the OpenDNS traffic.
Moving along, let’s make a Kibana data table to clean up our view a bit and we see
lcdixieeoe[.]com, of note are those long URI’s + an AVI file. Let’s use Docket to see what’s in those packets.
Hopping right into Exporting the HTTP objects, we see the
*.avi files we observed in Kibana’s
url.original field. Let’s save those and take a look.
In looking at the metadata for those “avi” files, we see that they’re actually just Text files.
======== B.avi ... File Name : B.avi File Type : TXT File Type Extension : txt MIME Type : text/plain ... ======== alSLK.avi ... File Name : alSLK.avi File Type : TXT File Type Extension : txt MIME Type : text/plain ... ======== jNjcj.avi ... File Name : jNjcj.avi File Type : TXT File Type Extension : txt MIME Type : text/plain ...
I poked and prodded on these files, but I’m not sure what they are…but I know they aren’t normal media files. It looks like Base64 encoding, but I’m not sure what order they’re supposed to be assembled in to decode. Either way, they have the
.avi file extension and certainly aren’t, so I’d put that in the suspect category.
... p1kTy18hM3gcANzilINMVJWdUP4AbxDka8IVGBACN+HkZxzdIOi86DoUwglmVgw+BsGdGC3WLgE45BoaeDFcYxpoS8/HzXcwtxxa45Wiqordymiv5JlqzxHWS647gV2B0XpV1+A5h9PTPvxdfJV/CIAYGgCqFLzlxXF3znojgEGWHj/MwRbhIgMIKm9FDqEQEqxjDIv0SC+sqN9TxpQLNPCdqJwMTuQN2sfat464J1bh9LWzHwPwyZXErBH5+XmvEbIjOX3ptyRJOa4C+W0Cf6yOFLIPWas659a0x5tZAQs1VbwMjylWLlx6LA2Dmop1C4dwb+zH5SSJrYo5RKbc6DV1AmmRpeJ1NXkO30Z2Bq27U+h3uRUnMulPWSp1uTeLwc8LSFK49kTIaV0lwWNfDeb975aPmPac6kZP/5g5xgfB5/53/kC2KvHCbMUF8RotemD2ak+Lc0gzP7W/pcmbw/ZhxmdFJd5rPJz1lhGIOEZX6buFkcg3vjsBInd319vLO+ZSZmbU8m1ZryNsfLZ56tEvbafgCY1Jz/tP4UdKL6DZPyjCXC7oIEoCO3yn/yHOaFFQvOFizv2OnUPVW3ST+BN/TwkHUSZfE1+lKvjXJBsONeaiAa5ozLa2uI/ebx1caPFMjw0j62H23r0YFd0opsTw2ovlkvKcx3eoT ...
Extract of a normal .avi files
RIFF,O AVI LIST�hdrlavih85� �"�LISTtstrlstrh8vidscvid�"�strf((�IV41JUNKLIST�; movi00db~ ���| ��`������@�|��@�P!����9���&��y��i��y���y��y>�����<��<��y���<��<��<��<��<��<��<��<��<��<��<��<��<��<��<��<��<��<ϲ<����<��<��<ϳ��<��<��<��(��<��<��,��<�S<��<��<��|��y��y>���<��<��<����|n��y��y���y>3��y��y��y�Qm<�� �Z�;d�����ߢS%����T��!~nV�&~RVG���(p& ��۹+��$g�E���V��� �q��b�Z0���I.B�k����X�+|dy:$�X1��9��'ҙ*� 9�1d!��P�x����l�y"d�m'a��#Ԏ&Z]�"�%����fzڬ��q"j�g�c�X�(�p��j��xs`�<Ĺg�R�$��pY�1� ( p6��� E s V�pɫ�Œ�vNaG�(q�9�����"*���% �k�8mY��f�."s�8 �(WL�!<-|=_���C&�ďo�s8��nj��T sh��YX�oB�B��(NᠱI��ib��8���Y\�'1A�.�B$t´pHfB<�9���A�n5Hf�R�D�� �g��9sVI���CsF!����2����S�Q�E�P��5Xj�txMF:�G�q�S��k�0N(3q]-��O�J��$��ID>��a� ����c' A9�� P@X
Trying a bit more on these files, 2 of these “avi” files end in
jNjcj.avi), so I am definitely leaning more towards Base64. The file that doesn’t end in a
alSLK.avi), I tried to append that to the top of the two files that do end in
= and then run
base64 -D -i [file] -o [file], it created binary files (which seems like progress), but no luck in taking it apart. If anyone has any ideas here, feel free to reach out.
Malware Traffic Analysis noted another indicator that was identified through the analysis of the infected Word documents (
q68jaydon3t[.]com), which we don’t have. So while we see the traffic, it is all over TLS minus the initial DNS request so there’s not much we can do for that. The
ja3s hash was collected. I’m adding it to the artifacts below, but this would only be “known bad” if it was found through analysis of the document.
194[.]61[.]2[.]16 95[.]169[.]181[.]35 45[.]141[.]103[.]204 (found by Malware Traffic Analysis) 8962cd86b47148840b6067c971ada128 7e34d6e790707bcc862fd54c0129abfa 40186e831cd2e9679ca725064d2ab0fb 2b93fcafabab58a109fcbca4377cccda qr12s8ygy1[.]com lcdixieeoe[.]com q68jaydon3t[.]com (found by Malware Traffic Analysis) xubiz8[.]cab /khogpfyc8n/215z9urlgz[.]php
Until next time, cheers and happy hunting!