In our last episode, we talked about network symptoms and then we talked about host symptoms.
It's no wonder that today we're going to talk about application symptoms.
It's important to remember that applications play an important role to any device or organization.
Without applications residing on the specific equipment and hardware that we utilize, we as cybersecurity
professionals really wouldn't have a job.
And so when we're looking at application symptoms, we need to go past the network infrastructure,
past the host infrastructure, and identify how we can relate those specific applications within its
confines of not only itself, but how it pulls that role on the host systems as well.
A lot of people like to separate applications from hosts like I just kind of mentioned, but really
they're kind of combined into one and we can see the symptoms residing not only in the host machine,
but also the application.
Yet the application is where usually we see the most problem application related symptoms can include
application Modification, meaning that we had a patch or we provided a security update to the normal
application.
Well, yes, this is a modification.
It's a authorized modification, meaning that we authorize went through the testing process we went
through and made sure that it conformed properly to not only the host machine, but to our other applications.
And we went through the rigorous testing and approval process to allow that modification of that original
software.
Unauthorized application modification comes into play when something changes within the application
that we weren't aware of or that we didn't authorize.
It's not uncommon for applications to come out with its own patching or new software update, but as
an organization, we need to control when those modifications take place.
We don't just willy nilly go into play and say update now, even though that's what most people do on
their home computers.
As the cyber security professionals, we need to make sure that the modifications taking place on our
host machines with our applications play nice with one another.
Unauthorized application modifications could mean that the application crashes unexpectedly, and it
could mean that there's a new vulnerability introduced to our system.
It can mean a variety of different things that we weren't aware of, or that we didn't properly test
when it was rolled out.
It could also mean that somebody went in and purposely modified that application to do something that
it wasn't originally designed for, without our knowledge, without the third party knowledge, and
just went in open different ports or changed the codings in such a way that introduced a vulnerability
within our system.
Usually we don't have employees going through and changing the code on our applications.
I know that's surprising, but what we do normally see is that employees will go on to a website and
see a brand new plugin, or a new feature that they want to download.
Zoom is a perfect example.
It has multiple plugins out there that you could update your system with that allow the user to have
better experiences with the zoom platform.
However, not all of those are necessarily secure or provided by the organization in such a manner that
allows us to control them And so a lot of organizations just don't allow for that.
However, you've always got that employee that wants to upgrade to the newest plugin to update to the
newest feature that that software provides.
This is where the problem comes into play that we as cybersecurity specialists, need to be aware of,
and that our employees aren't really going to follow our processes and procedures to the key.
We utilize technology to prohibit this.
We also utilize policies and procedures to stop that from happening.
But it does occur, and we need to be aware of those occurrences in order to stop them and rule back
that, that that application.
There's also something called privilege escalation.
Privilege escalation occurs when a software process or an application exceeds its authorized permissions.
Obviously, if I have a new application, I want it to just download to my machine and have minimal
privileges on that device.
Um, my three year old, for instance, when he was a kid, he would go through and he would just start
downloading apps all over the place.
He would just one after another.
It would be Angry Birds to this Star Wars game, to this game that was about light birds and letters.
You get the point.
Just all kinds of different applications.
Those applications didn't play well with each other, and they would normally cause other applications
that he had going on simultaneously on his tablet to crash.
Now, I know I'm talking a tablet and you would be thinking to yourself, well, wait a second, a tablet
in a organization?
I don't think so, but stick with me on this one.
Throughout those applications that he was modifying, it also allowed different privileges associated
with each application.
In less than six months, my three year old came up to me and he said, daddy, my tablet doesn't work
anymore.
When I got his tablet and I started running through it, he hadn't managed to download over 257 different
viruses onto his system.
That's 257 malwares in less than six months.
Now, obviously Non-employees are a three year old, and so there's a little bit of difference in there.
But in many cases, if we let our employees just run rampant, they're going to do the same thing.
We need to lock down our machines, and we need to make sure those applications don't have unauthorized
privileges.
When we go through as a cyber security analyst, you need to look at processes and applications is what
are they authorized to do versus what they aren't authorized to do?
On my own normal mobile device, I don't authorize applications to track me.
That's just something I don't allow.
Your computer systems shouldn't allow the different escalation and privileges associated with those
different machines.
Some make sense, right?
If I'm using a mapping program on my mobile device, obviously I want it to be able to locate and know
where I'm at while I'm using the application.
But if it's not using the application, it shouldn't have permissions that it doesn't need, i.e. it
shouldn't be able to track me.
Now, I know that's just my personal devices, but think about that from an organizational point of
view.
What are different applications inside your work environment and what permissions do they have accessibility
to?
Are they able to modify other applications?
Are they able to identify and reach out to command and control servers?
Are they able to pull in different files from other different applications or programs on the computer
that they're utilizing?
All of these are dangerous permissions that we should stop whenever possible, unless the application
has a legitimate use in order to proceed with them.
There was an application that came out about a year and a half ago that I was privy to, and they rolled
it out and it was able to pull from different cloud environments simultaneously.
Now, obviously, that could be a dangerous front where I've got 6 or 7 different cloud platforms interacting
in one device, and this application on this computer is able to pull from all seven of them.
But that was a normal privilege that was authorized for that application.
And it went through a review process as well as an authorization process that's in privileged escalation
that we approved.
However, when we're talking about privilege escalation from a cyber security standpoint, it's unapproved
escalation of privileges associated with either the person, the application or the device.
There are different application related symptoms that come into play with each application associated
with it.
For instance, an antivirus program may give you something like this where it's saying, hey, there's
unauthorized spyware or there's another problem on it.
It wasn't that long ago I think in 2013, where there was a particular nasty malware that would pop
up saying you're Adobe Acrobat needs to be updated, and users would take this for granted and they'd
say, yes, update now.
However, it wouldn't go to the Adobe Acrobat web page.
It would go to a fake web page that looked like Adobe Acrobat, that then went download malware into
their system, and it remained uncaught for very for about six months.
If I remember correctly, this is a dangerous related malware that utilizes the same processes and procedures
that users expect to see on their own devices.
Obviously, as cybersecurity professionals, we want to relate or negate those pop up windows as much
as possible and have full control over those security related applications.
For instance, in this one, you can see that it detected 25 critical system objects, and it's going
on and saying, should I remind me later or should I register the product?
This is a known scam that comes into play with antivirus programs, where they're trying to get you
to register the product in order to pay them extra money.
Obviously, this isn't something we should normally see on our organization, but it does occur every
once in a while.
If you have users that are experiencing a pop up windows like this, this could be an indicator of compromise
at an application level, and we need to do a full virus scan and malware scan in order to identify
what's going on within the system, and then remove those unauthorized programs from our systems.
Botnet activity really comes into play, where I've got a command and control system outside of my network,
and the client has been attached with malware, meaning that the client or the host machine has been
infected, and it's sending out that beacon across our network to communicate with a command and control
system.
Now, we talked about command and control systems and the network systems, and we identified how the
command and control, or Beaconing could play a role in indicator of compromise.
However, within that beacon, it comes back to an application or even a client associated with it.
Within botnet activity, our own systems within our within our organization could actually be providing
malicious activity across not only our own network, but neighboring networks as well, and third party
vendors.
This could lead to malicious activity and denial of service activity across different applications and
different systems.
We could actually see some problems related from our system exfiltration or our data going through.
Data exfiltration is something that is usually hidden within a DDoS attack, and it's not uncommon to
see where our own network is being dosed and the user or the malicious actor is trying to exfiltrate
data simultaneously.
While our cybersecurity staff is trying to deal with this DDoS attack secretly, they're on the back
end expelling data, making it to where our our sensitive information, our proprietary data is then
leaving our network.
Both of those don't seem like they go hand in hand with one another, but it's a common tactic used
by malicious actors.
You need to be aware of these tactics and techniques that are used by actors, so that you can better
prepare and defend against them.
Botnet activity is the first point of that, seconded by data Exfiltration through email or even normal
traffic patterns.
Remember, whenever we're undergoing an attack, you should take the idea that there isn't just one
attack going on.
There's usually something else associated with it.
While that not always happens, it is pretty indicative of normal strategies that we're seeing in common
day malware attacks.
There's also phishing communication.
Phishing communication is pretty standard for social engineering.
And we see phishing.
We see phishing, we see smishing.
And I feel like I should break that down.
So let's let's go through this right.
Phishing communication is broad communication associated with emails where we're hitting the entire
organization.
And it's very broad in scope because it's not really identifying a key person within it.
That's phishing communication with the general ideology that we're trying to get them to click on a
link that would either download email or even open a secure communication between that client computer
and an off network computer in order for them to invade our computer systems, usually using something
like RDP or even SSH.
There's also something called spearfishing.
And I think you should know this from your security plus days.
Spearfishing is where we target a specific individual, usually commonly noted with fishing as well.
But we have personal identifiers in there like their name, maybe their title, even their phone number.
And we could utilize this on different applications within there.
Then there's also smishing or texting phishing with voice phishing or robocalls and that kind of thing.
You have to remember that while those are all social engineering attacks, they very much come into
play with the application related attack measures that we see from malicious actors, whether it's through
phishing or even smishing where they're company phone is hit with a link.
You need to understand that as an analyst, we need to be prepared for those various attack vectors
when they come into play with our organization.
Anomalous activity usually comes in the form of phishing attacks or even smishing or social engineering
attacks, but it can also come in the form of a process or a application doing something that it shouldn't
normally do.
Usually we relate this to privilege escalation or some other form of attack.
But when it really comes down to it, anomalous activity is an activity on our system or on our client
that isn't authorized and doesn't have a known normal link to another objective.
Meaning that usually a malware hasn't been involved, but somebody opened up a port in order to communicate,
or we downloaded an antivirus program, and the antivirus program is picking up the viruses, but it
missed one because it wasn't updated properly.
Anomalous activity can be any number of things, but what it really includes is something that we haven't
seen before, or it can't be directly linked to another activity that's malicious in nature.
This can take the form of new accounts where an actor gets in there and he starts creating new accounts
that make sense or don't make sense.
For instance, when I was with AT&T, um, it used to be our first letter of our initial, the second
letter of our initial, and then a random pseudo number letter combination.
And that would be the user ID that we utilize for our entire career with AT&T.
If we had new accounts that were popping up that didn't have that format, we knew that there was a
problem and somebody had gained an entry into our system and started creating new accounts.
However, that's not always the case.
If a malicious actor really knows what's going on, they can duplicate our same procedure and start
creating new accounts.
If we see a rash of new accounts that don't make a lot of sense, that could be indicative of an indicator
of compromise.
We also often see service interruptions with malware, and new applications, or new policies or procedures
come into play.
We often see service interruptions.
Usually this comes into an authorized aspect during our maintenance window, but not always.
If I'm seeing a service interruption where a machine or a software within a host environment, i.e.
a server or something else comparable to that is no longer available during normal regular business
hours, and I can't attribute it to something I need to investigate and find out why.
Usually this is regulated to the IT department, but as a cybersecurity analyst, you should be aware
that not everything is an IT problem.
If we're seeing crashes in software that could be associated with an application or with another process
interfering with that, uh, corresponding service.
And so service interruptions can play a role within the cyber environment.
This is why having a direct communication with the IT department and having a good working relationship
with them really expands upon our capabilities as a cyber security workforce.
And so, again, we need to make sure that we have a good working environment with our IT staff.
Finally, there's application logs just like IPS, IDs, firewalls and anything else on our network.
Applications have logs too.
Some logs we want to collect, some we don't.
And it really kind of confines itself to what is important within our own organization.
Regardless of what we collect for our Siem environment or not, we need to make sure that we always
have those application logs available to us so that we can go back if we see a problem within our network
or within our applications, those logs can provide us alerts.
They can provide us keys into what's going on and what's going what's happening with that specific application
and how it interferes with other applications on there.
This also allows us to quickly identify if there was a legitimate process that just had a legitimate
issue that our IT staff could take care of, or if there was something more nefarious going on and where
our cyber team needs to get involved.
Those application logs are key to identifying key features within our cybersecurity environment, and
can lead us down the road to identifying what's really going on within our applications environment,
as well as our network environment.
Throughout this course, we identify different applications and how they intersect with our host and
even network environment.
We also identified how they can be utilized within a cyber scope, whether from an IT perspective or
a security perspective.
It's important to note for Cisa, you're probably not going to see a lot of questions from the technical
perspective, we're not going to ask you, here's a log of an application.
How what's going on with this other application.
It's too narrowly defined.
And Cisa doesn't expect you to know that.
But what they do expect you to understand is simple things like this application is then is now able
to interact or intersect with this other application that has nothing to do with it, i.e. maybe I have
an application that's associated with word and it's intersecting or interacting with an application
for maps.
There's really no straight route for those two.
So why are they able to feed off information from one another?
And then they'll ask you, is this an authorized permission or what kind of permission should we investigate
further within our within our strategy?
Remember, most of the Sisa questions are scenario based, so you should be really prepared to read
through and a paragraph full of information and then quickly identify what's going on.
Now this is a very high level question answer scenario for most of these questions in Sisa.
So again, we're not expecting you to be able to read the individual application logs, but we are expecting
you to be able to read network logs.
So there's that fine line at eliminator between the two that you need to prepare for.
Sisa.