You are browsing the archive for Malware Analysis.

SCCM (System Center Configuration Manager) and Incident Response – Part 2

January 30, 2015 in Compromise Detection, Forensic Analysis, Malware Analysis, Security Control

Update

After I posted this piece Ryan (Thanks!) pinged me to highlight a few aspects related to SCCM which are worth mentioning, so I am adding some more notes below:

  • For performances reasons the indexing is often limited to certain directories and file extensions; this is a very important point and it’s good to review the inventory config and adjust it accordingly to your needs (if SCCM admins agree :) )
    • I have seen inventories limited to .exe files, and multimedia files (e.g. mp3)
  • There is an option to copy files to SCCM
  • SCCM can be asked to query the environment for specific file names (even non .exe) – it is kinda similar to sweeps, but it’s relatively slow and quite a burden to the system
  • You may know SCCM as SMS (Systems Management Server), ConfigMgr 2012, ConfigMgr 2007 or ConfigMgr) – see wiki for more details

Old post

A while ago I wrote that SCCM can help IR guys to hunt for anomalies in the environment. I always wanted to come back to this topic with some more concrete examples so that I can show what is actually possible.

As mentioned in the first post – if you never used SCCM or don’t know what it is please ask your admin or whoever owns the ‘win’ platform in your company (the function may be called Desktop Management, Windows Admin, or sth along these lines) to give you the URL (and access rights) to the SCCM reporting tool.

The URL will lead you to a page where you can choose various reports presenting information about asset inventory of your company. I won’t cover the details here – all you need to do is to choose a specific report, fill-in the form and submit it to the web site. In return you will get the report.

An example form looks like this:

sccm1The screenshot comes from some random forum post so I hid the domain name to protect the innocent.

When you submit this form the data will be sent to the web site using a GET request. This is cool, because it means you can dynamically change them in your browser’s address bar – it’s easy to experiment with the variable holding the file name.

Let’s see how it works like in practice.

The URL to your SCCM report looks like this:

http://<SCCM>/Report.asp?ReportID=<###>

where:

  • SCCM = address of your SCCM reporting page – usually sth like “SMSReporting_<org name>/”
  • ### – a number assigned to the report called “Computers with a specific file” (find it on the main SCCM reporting page)

The data you provide is passed via an argument called ‘variable’.

Submitting an example query to show all computers that host ‘tor.exe’ could look like this:

http://<SCCM>/Report.asp?ReportID=<###>&variable=tor.exe

When the page comes back you can get 3 types of reports:

  • No report, because the page timed out ;) – you need to use a different query (most likely, the tor.exe query won’t time out since the name is quite unique, but if you searched f.ex. for notepad.exe the chances are high).
Response object error 'ASP 0251 : 80004005'
Response Buffer Limit Exceeded
[...]
  • No results – this is usually good news, since it means there is no ‘tor.exe’ on any system
  • The actual list of systems hosting ‘tor.exe’ – these you need to chase after ASAP

The example report highlighting one system hosting ‘tor.exe’ looks like this:

sccm2

This is a good example of an actionable data. You can now go directly to the system and investigate. You can question the owner of the system. Finally, you can remove that ‘tor.exe’ instance from the system.

Obviously, to make the best use of the tool you need to know what queries to use. There is (luckily) a long list of tool names and programs both hackers and admins (as well as stupid users) use and you can start the hunting initiative querying f.ex. for:

http://<SCCM>/Report.asp?ReportID=<###>&variable=nmap.exe
http://<SCCM>/Report.asp?ReportID=<###>&variable=psexec.exe
http://<SCCM>/Report.asp?ReportID=<###>&variable=psexesvc.exe
http://<SCCM>/Report.asp?ReportID=<###>&variable=tor.exe
http://<SCCM>/Report.asp?ReportID=<###>&variable=vidalia.exe
http://<SCCM>/Report.asp?ReportID=<###>&variable=%25torrent%25.exe
http://<SCCM>/Report.asp?ReportID=<###>&variable=[0-9][0-9][0-9].exe

The last 2 examples contain wildcards (looking for torrent clients) and regular expressions (looking for 3-digit file names) – it is very handy that these are supported by SCCM – they not only help us with more complicated queries, but also narrow down the results (otherwise the time out will tell you your query was not that good :) ).

Once you define what queries you want to run on regular basis you can automate it using Visual Basic Script, python, or whatever else you like. You can also start building white lists or exclusions lists. This is because SCCM has a tendency to keep some records ‘forever’ and even if you clean up the system sometimes you may find some old records ‘hanging’ in SCCM for a very long time. You can either delete them manually directly from SCCM DB, or just keep them there, and also use the aforementioned ‘ignore’ lists to automatically exclude these known systems / files from the output of your parser. Going even further you can report it to SIEM, or you can start sending alerts via email.

The web based report is cool, but it has a serious limitation. It only accepts very simple queries. You can add more fields to the form (e.g. location), but still, it will be quite difficult to use it on regular basis. This is because the inner workings of this form rely on a very simple SELECT query.

If you want more (and you should), the natural progression is therefore talking directly to the SQL Database. Once you know the DB schema you can start creating very specific queries f.ex.:

  • Show me all files added to any system that are dropped under c:\windows within last 8h
  • Show me all files dropped under user profile
  • Show me all files with a single letter file name
  • Show me all files made up of digits only
  • etc.

Using time intervals you can build automatic reports about all .exe files added within last XYZ hours. Eyeballing this may be a bit tricky (don’t be surprised to see gazillions of new .exes landing in your corporate environment every day), so implementing some ‘ignore’ lists may really come handy. In any case, the sky is the limit here and a bunch of SCCM queries ran on regular basis can become a very strong complementary detective security control. Note that you don’t need to install anything, build anything, run sweeps, etc. It’s all there, juicy data waiting to be queried.

Btw. if you are wondering why I am not providing example SQL queries it is because they will vary. Table names are usually organization-specific. If you are curious you can just google around for “sccm sql SoftwareFile” and you will find plenty of examples.

While SCCM can’t be obviously as flexible as a dedicated IR solution it can give you an edge if you don’t have plans /or budget/ to deploy something more IR-centric. Apart from a typical malware / hacking angle, it may also help you to keep systems ‘clean’ for auditing purposes, discover malicious insiders, and perhaps even win a few brownie points from your management.

Beyond good ol’ Run key, Part 26

January 28, 2015 in Anti-Forensics, Autostart (Persistence), Compromise Detection, Forensic Analysis, Malware Analysis

Today I cheated. I wrote two posts in a go, because 25 is not that interesting from the persistence perspective.

So, as promised 5 minutes ago, this post is about yet another Frankenstein’s monster. It focuses on a bug that I have already covered, but intentionally didn’t explore its most crazy aspect yet.

Bugs in dynamically loaded libraries are surely interesting, but even more interesting are the bugs in the libraries that are linked statically.

Why?

Because patching these is really hard and you can’t just submit a single patch to fix it all (unless you do some magic).

So, as mentioned above – the very same code that we have explored in the part 21 inside the MFC libraries is present in many popular applications as it’s linked with them statically.

This is bad news.

The result is that finding such vulnerable applications can give an attacker a myriad of persistence opportunities as all he has to do is to find a vulnerable static library pattern in a .exe or .dll and drop a ‘localization DLL’ in a respective directory. Yes, the statically linked code has a side effect and loads localization DLLs for DLLs as well. So if your foo.dll contains the vulnerable code, dropping fooENU.dll or fooLOC.dll on English system will ensure they are loaded as well.

There are really a lot of applications containing this buggy code. Looking through a couple of apps I was able to quickly spot them inside many omnipresent executables and DLLs.

So, without further ado, this is a very short list of files that I found to contain the specific vulnerable code:

  • %APPDATA%\Local\Akamai\ControlPanel.exe
    • %APPDATA%\Local\Akamai\ControlPanelENU.dll
    • %APPDATA%\Local\Akamai\ControlPanelLOC.dll
  • c:\Program Files (x86)\HP\HP Software Update\hpwucli.exe
    • C:\Program Files (x86)\HP\HP Software Update\hpwucliENU.dll
    • C:\Program Files (x86)\HP\HP Software Update\hpwucliLOC.dll
  • c:\Program Files\Realtek\Audio\HDA\RtHDVCpl.exe
    • C:\Program Files\Realtek\Audio\HDA\RtHDVCplENU.dll
    • C:\Program Files\Realtek\Audio\HDA\RtHDVCplLOC.dll
  • c:\Program Files\Realtek\Audio\HDA\RtkNGUI64.exe
    • C:\Program Files\Realtek\Audio\HDA\RtkNGUI64ENU.dll
    • C:\Program Files\Realtek\Audio\HDA\RtkNGUI64LOC.dll
  • c:\Program Files (x86)\Western Digital\WD Utilities\WDDriveUtilitiesHelper.exe
    • C:\Program Files (x86)\Western Digital\WD Utilities\WDDriveUtilitiesHelperENU.dll
    • C:\Program Files (x86)\Western Digital\WD Utilities\WDDriveUtilitiesHelperLOC.dll
  • C:\Program Files\Western Digital\WD SmartWare\WD Quick Formatter.exe
    • C:\Program Files\Western Digital\WD SmartWare\WD Quick FormatterENU.dll
    • C:\Program Files\Western Digital\WD SmartWare\WD Quick FormatterLOC.dll
  • c:\Program Files (x86)\ATI Technologies\ATI.ACE\Core-Static\SLSTaskbar.exe
    • C:\Program Files (x86)\ATI Technologies\ATI.ACE\Core-Static\SLSTaskbarENU.dll
    • C:\Program Files (x86)\ATI Technologies\ATI.ACE\Core-Static\SLSTaskbarLOC.dll

As you can see a few prominent vendors. It works for both 32- and 64-bit applications and DLLs.

This is a tip of the iceberg of course and if you scan any average hard drive you will surely find at least one vulnerable app like this.

I guess there may be even cases where such localization DLL can lead to an escalation of privileges if any of the vulnerable components is executed/loaded by a more privileged process/account.

Should this be reported as a vulnerability? Yes. But I really don’t know to who.