Login
Many things have changed since 2018, such as the names of the companies in the Fortune 100 list. But one aspect of that vaunted list that hasn’t shifted much since is that very few of these companies list any security professionals within their top executive ranks.
The next time you receive a breach notification letter that invariably says a company you trusted places a top priority on customer security and privacy, consider this: Only five of the Fortune 100 companies currently list a security professional in the executive leadership pages of their websites. This is largely unchanged from five of the Fortune 100 in 2018, the last time KrebsOnSecurity performed this analysis.
A review of the executives pages published by the 2022 list of Fortune 100 companies found only five — BestBuy, Cigna, Coca-Cola, Disney and Walmart — that listed a Chief Security Officer (CSO) or Chief Information Security Officer (CISO) in their highest corporate ranks.
One-third of last year’s Fortune 100 companies included a Chief Technology Officer (CTO) in their executive stables; 40 listed Chief Information Officer (CIO) roles, but just 21 included a Chief Risk Officer (CRO).
As I noted in 2018, this is not to say that 95 percent of the Fortune 100 companies don’t have a CISO or CSO in their employ: A review of LinkedIn suggests that most of them in fact do have people in those roles, and experts say some of the largest multinational companies will have multiple people in these positions.
But it is interesting to note which executive positions the top companies deem worth publishing in their executive leadership pages. For example, 88 percent listed a Director of Human Resources (or “Chief People Officer”), and 37 out of 100 included a Chief Marketing Officer.
Not that these roles are somehow more or less important than that of a CISO/CSO within the organization. Nor is the average pay hugely different among all these roles. Yet, considering how much marketing (think consumer/customer data) and human resources (think employee personal/financial data) are impacted by your average data breach, it’s somewhat remarkable that more companies don’t list their chief security personnel among their top ranks.
One likely explanation as to why a great many companies still don’t include their security leaders within their highest echelons is that these employees do not report directly to the company’s CEO, board of directors, or Chief Risk Officer.
The CSO or CISO position traditionally has reported to an executive in a technical role, such as the CTO or CIO. But workforce experts say placing the CISO/CSO on unequal footing with the organization’s top leaders makes it more likely that cybersecurity and risk concerns will take a backseat to initiatives designed to increase productivity and generally grow the business.
“Separation of duties is a fundamental concept of security, whether we’re talking about cyber threats, employee fraud, or physical theft,” said Tari Schreider, an analyst with Datos Insights. “But that critical separation is violated every day with the CISO or CSO reporting to the heads of technology.”
IANS, an organization geared toward CISOs/CSOs and their teams, surveyed more than 500 organizations last year and found roughly 65 percent of CISOs still report to a technical leader, such as the CTO or CIO: IANS found 46 percent of CISOs reported to a CIO, with 15 percent reporting directly to a CTO.
A survey last year by IANS found 65 percent of CISOs report to a tech function within organizations, such as the CTO or CIO. Image: IANS Research.
Schreider said one big reason many CISOs and CSOs aren’t listed in corporate executive biographies at major companies is that these positions often do not enjoy the same legal and insurance protections afforded to other officers within the company.
Typically, larger companies will purchase a “Directors and Officers” liability policy that covers legal expenses should one of the organization’s top executives find themselves dragged into court over some business failing on the part of their employer. But organizations that do not offer this coverage to their security leaders are unlikely to list those positions in their highest ranks, Schreider said.
“It’s frankly shocking,” Schreider said, upon hearing that only four of the Fortune 100 listed any security personnel in their top executive hierarchies. “If the company isn’t going to give them legal cover, then why give them the responsibility for security? Especially when CISOs and CSOs shouldn’t own the risk, yet the majority of them carry the mantle of responsibility and they tend to be scapegoats” when the organization eventually gets hacked, he said.
Schreider said while Datos Insights focuses mostly on the financial and insurance industries, a recent Datos survey echoes the IANS findings from last year. Datos surveyed 25 of the largest financial institutions by asset size (two of which are no longer in existence), and found just 22 percent of CSOs/CISOs reported to the CEO. A majority — 65 percent — had their CSOs/CISOs reporting to either a CTO or CIO.
“I’ve looked at these types of statistics for years and they’ve never really changed that much,” Schreider said. “The CISO or CSO is in the purview of the technical stack from a management perspective. Right, wrong or indifferent, that’s what’s happening.”
Earlier this year, IT consulting firm Accenture released results from surveying more than 3,000 respondents from 15 industries across 14 countries about their security maturity levels. Accenture found that only about one-third of the organizations they surveyed had enough security maturity under their belts to have integrated security into virtually every aspect of their businesses — and this includes having CISOs or CSOs report to someone in charge of overseeing risk for the business as a whole.
Not surprisingly, Accenture also found that only a third of respondents considered cybersecurity risk “to a great extent” when evaluating overall enterprise risk.
“This highlights there is still some way to go to make cybersecurity a proactive, strategic necessity within the business,” the report concluded.
One way of depicting the different stages of security maturity.
A spreadsheet tracking the prevalence of security leaders on the executive pages of the 2022 Fortune 100 firms is available here.
Update, July 23: Somehow overlooked Disney’s CSO listed on their leadership page. The story copy above has been updated to reflect that.
If you have seen the film Spartacus from 1960, you will remember the scene where the Romans are asking for Spartacus to give himself up. The moment the real Spartacus stood up, a lot of others stood up as well and claimed to be him using the "I AM SPARTACUS" phrase.
When a process that is vulnerable to DLL Hijacking is asking for a DLL to be loaded, it's kind of asking "WHO IS VERSION.DLL?" and random directories start claiming "I AM VERSION.DLL" and "NO, I AM VERSION.DLL". And thus, Spartacus.
...but with a twist as Spartacus is utilising the SysInternals Process Monitor and is parsing raw PML log files. You can leave ProcMon running for hours and discover 2nd and 3rd level (ie an app that loads another DLL that loads yet another DLL when you use a specific feature of the parent app) DLL Hijacking vulnerabilities. It will also automatically generate proxy DLLs with all relevant exports for vulnerable DLLs.
FreshRSS 
version.dll, Spartacus will create a version.dll.cpp file for you with all the exports included in it. Then you can insert your payload/execution technique and compile.[Defence] Monitoring mode trying to identify running applications proxying calls, as in "DLL Hijacking in progress". This is just to get any low hanging fruit and should not be relied upon.DllMain. This technique was inspired and implemented from the walkthrough described at https://www.redteam.cafe/red-team/dll-sideloading/dll-sideloading-not-by-dllmain, by Shantanu Khandelwal. For this to work Ghidra is required.CreateFile..dll.procmon.exe or procmon64.exe.Drop Filtered Events to ensure minimum PML output size.Auto Scroll.ENTER.| Argument | Description |
|---|---|
--pml | Location (file) to store the ProcMon event log file. If the file exists, it will be overwritten. When used with --existing-log it will indicate the event log file to read from and will not be overwritten. |
--pmc | Define a custom ProcMon (PMC) file to use. This file will not be modified and will be used as is. |
--csv | Location (file) to store the CSV output of the execution. This file will include only the DLLs that were marked as NAME_NOT_FOUND, PATH_NOT_FOUND, and were in user-writable locations (it excludes anything in the Windows and Program Files directories) |
--exe | Define process names (comma separated) that you want to track, helpful when you are interested only in a specific process. |
--exports | Location (folder) in which all the proxy DLL files will be saved. Proxy DLL files will only be generated if this argument is used. |
--procmon | Location (file) of the SysInternals Process Monitor procmon.exe or procmon64.exe
|
--proxy-dll-template | Define a DLL template to use for generating the proxy DLL files. Only relevant when --exports is used. All #pragma exports are inserted by replacing the %_PRAGMA_COMMENTS_% string, so make sure your template includes that string in the relevant location. |
--existing-log | Switch to indicate that Spartacus should process an existing ProcMon event log file (PML). To indicate the event log file use --pml, useful when you have been running ProcMon for hours or used it in Boot Logging. |
--all | By default any DLLs in the Windows or Program Files directories will be skipped. Use this to include those directories in the output. |
--detect | Try to identify DLLs that are proxying calls (like 'DLL Hijacking in progress'). This isn't a feature to be relied upon, it's there to get the low hanging fruit. |
--verbose | Enable verbose output. |
--debug | Enable debug output. |
--generate-proxy | Switch to indicate that Spartacus will be creating proxy functions for all identified export functions. |
--ghidra | Used only with --generate-proxy. Absolute path to Ghidra's 'analyzeHeadless.bat' file. |
--dll | Used only with --generate-proxy. Absolute path to the DLL you want to proxy. |
--output-dir | Used only with --generate-proxy. Absolute path to the directory where the solution of the proxy will be stored. This directory should not exist, and will be auto-created. |
--only-proxy | Used only with --generate-proxy. Comma separated string to indicate functions to clone. Such as 'WTSFreeMemory,WTSFreeMemoryExA,WTSSetUserConfigA' |
Collect all events and save them into C:\Data\logs.pml. All vulnerable DLLs will be saved as C:\Data\VulnerableDLLFiles.csv and all proxy DLLs in C:\Data\DLLExports.
--procmon C:\SysInternals\Procmon.exe --pml C:\Data\logs.pml --csv C:\Data\VulnerableDLLFiles.csv --exports C:\Data\DLLExports --verbose
Collect events only for Teams.exe and OneDrive.exe.
--procmon C:\SysInternals\Procmon.exe --pml C:\Data\logs.pml --csv C:\Data\VulnerableDLLFiles.csv --exports C:\Data\DLLExports --verbose --exe "Teams.exe,OneDrive.exe"
Collect events only for Teams.exe and OneDrive.exe, and use a custom proxy DLL template at C:\Data\myProxySkeleton.cpp.
--procmon C:\SysInternals\Procmon.exe --pml C:\Data\logs.pml --csv C:\Data\VulnerableDLLFiles.csv --exports C:\Data\DLLExports --verbose --exe "Teams.exe,OneDrive.exe" --proxy-dll-template C:\Data\myProxySkeleton.cpp
Collect events only for Teams.exe and OneDrive.exe, but don't generate proxy DLLs.
--procmon C:\SysInternals\Procmon.exe --pml C:\Data\logs.pml --csv C:\Data\VulnerableDLLFiles.csv --verbose --exe "Teams.exe,OneDrive.exe"
Parse an existing PML event log output, save output to CSV, and generate proxy DLLs.
--existing-log --pml C:\MyData\SomeBackup.pml --csv C:\Data\VulnerableDLLFiles.csv --exports C:\Data\DLLExports
Run in monitoring mode and try to detect any applications that is proxying DLL calls.
--detect
Create proxies for all identified export functions.
--generate-proxy --ghidra C:\ghidra\support\analyzeHeadless.bat --dll C:\Windows\System32\userenv.dll --output-dir C:\Projects\spartacus-wtsapi32 --verbose
Create a proxy only for a specific export function.
--generate-proxy --ghidra C:\ghidra\support\analyzeHeadless.bat --dll C:\Windows\System32\userenv.dll --output-dir C:\Projects\spartacus-wtsapi32 --verbose --only-proxy "ExpandEnvironmentStringsForUserW"
Note: When generating proxies for export functions, the solution that is created also replicates VERSIONINFO and timestomps the target DLL to match the date of the source one (using PowerShell).
Below is the template that is used when generating proxy DLLs, the generated #pragma statements are inserted by replacing the %_PRAGMA_COMMENTS_% string.
The only thing to be aware of is that the pragma DLL will be using a hardcoded path of its location rather than trying to load it dynamically.
#pragma once
%_PRAGMA_COMMENTS_%
#include <windows.h>
#include <string>
#include <atlstr.h>
VOID Payload() {
// Run your payload here.
}
BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpReserved)
{
switch (fdwReason)
{
case DLL_PROCESS_ATTACH:
Payload();
break;
case DLL_THREAD_ATTACH:
break;
case DLL_THREAD_DETACH:
break;
case DLL_PROCESS_DETACH:
break;
}
return TRUE;
}If you wish to use your own template, just make sure the %_PRAGMA_COMMENTS_% is in the right place.
Whether it's a typo, a bug, or a new feature, Spartacus is very open to contributions as long as we agree on the following:
