HuntOps
2/24/2020 - Ursnif
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, 194[.]61[.]2[.]16 and 10.2.11.101.
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.
Using 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.
Of note, 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 95[.]169[.]181[.]35 and 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.
Extract of B.avi
...
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 = (B.avi and 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 (45[.]141[.]103[.]204 and 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 ja3 nor 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.
Detection Logic
Additional analysis, modeling, and signatures (KQL and Yara).
Artifacts
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!